bug: Workflow tasks bypass <code>concurrent_limiter</code> entirely

[hariom888]

Root Cause

Both workflows.py::_run_workflow() and routes.py::run_workflow_once() call executor.execute_task(task_id) directly without acquiring a concurrency slot:

# workflows.py line 76
task_id = await executor.create_task(plugin_id, inputs, ...)
asyncio.create_task(executor.execute_task(task_id))   # ← no acquire()
routes.py line 984
asyncio.create_task(executor.execute_task(task_id))   # ← no acquire()

The start_task route correctly calls concurrent_limiter.acquire(task_id) before scheduling. Workflow-triggered tasks skip this entirely, meaning a workflow with 10 steps launches 10 concurrent scans regardless of max_concurrent. This also means execute_task's finally block calls concurrent_limiter.release(task_id) for a slot that was never acquired — a silent no-op that masks the problem.

Minimal Fix

In both locations, acquire before scheduling and handle failure:

# workflows.py and routes.py — same pattern
can_acquire, _ = await concurrent_limiter.acquire(task_id)
if not can_acquire:
    await executor.mark_task_failed(task_id, reason="Concurrency limit reached")
    continue  # skip scheduling this step
asyncio.create_task(executor.execute_task(task_id))

[hariom888]

Hi @utksh1, I'd like to work on this issue under GSSoC'26. I analyzed backend/secuscan/workflows.py::_run_workflow() and backend/secuscan/routes.py::run_workflow_once().

Root cause: Both workflow execution paths call asyncio.create_task(executor.execute_task(task_id)) without calling concurrent_limiter.acquire(task_id) first. The start_task route correctly acquires a slot, but workflow-triggered tasks bypass the limiter entirely. A workflow with N steps launches N simultaneous scans regardless of max_concurrent. The release() call in execute_task's finally block silently no-ops because no slot was ever held.

Proposed fix:

• Call concurrent_limiter.acquire(task_id) after create_task() in both locations
• On failure, call executor.mark_task_failed(task_id, ...) and skip scheduling that step
• Add a test asserting that a workflow with more steps than max_concurrent leaves excess tasks as failed rather than running all simultaneously

Mirrors the pattern already applied to start_task. No API changes. Please assign this to me. Thanks!

[gyana07op]

Hi @utksh1 , I looked into this issue and found that workflow-triggered tasks are bypassing the concurrency limiter by calling executor.execute_task(task_id) directly without acquiring a slot first. Because of this, workflows can exceed the max_concurrent limit and the release call becomes a silent no-op.

I’d love to work on fixing this by adding proper concurrent_limiter.acquire() handling in both workflows.py and routes.py before scheduling tasks. Kindly assign this issue to me.

[aaniya22]

Hi, I would like to work on this issue under GSSoC'26.
Please assign this to me. Thank you!

[gyana07op]

Thank you for assigning this issue @utksh1 .I have understood the root cause and will start working on the fix right away and will try to resolve it as soon as possible.