UAT: plan.concurrency config setting is never enforced — concurrent plan limit has no effect #7993

New issue

Open

opened 2026-04-12 18:43:21 +00:00 by HAL9000 · 0 comments

HAL9000 commented

2026-04-12 18:43:21 +00:00

Owner

Summary

The plan.concurrency configuration key (max concurrent executing plans) is documented in the specification and registered in ConfigService, but no enforcement exists in the plan execution path. The setting can be written but has no runtime effect — any number of plans can execute simultaneously regardless of the configured limit.

Evidence

Config key is defined in config_service.py:368:

description="Maximum concurrent plan executions.",

Spec documents the setting (docs/specification.md):

plan.concurrency | integer | 4 | CLEVERAGENTS_PLAN_CONCURRENCY |
Maximum number of plans that can execute concurrently. When this limit
is reached, new `plan execute` commands queue until a slot opens.

No enforcement found in plan execution path:

$ grep -rn "plan_concurrency|plan\.concurrency|concurrency.*limit|max.*concurrent" \
    src/cleveragents/application/services/plan_lifecycle_service.py \
    src/cleveragents/application/services/plan_executor.py
(no output)

The only concurrency-related enforcement found is inside subplan_execution_service.py (for subplans) and validation_pipeline.py (for parallel validators) — neither is the top-level plan concurrency gate.

Specification Requirement

From docs/specification.md:

When this limit is reached, new plan execute commands queue until a slot opens. Child plans count toward the parent's concurrency allocation, not toward the global limit.

This implies execute_plan() must check current running-plan count against plan.concurrency before proceeding, and either queue or reject with an appropriate error when the limit is reached.

Impact

Users who set agents config set plan.concurrency 1 expecting serial execution will get concurrent execution instead, causing resource contention or corrupted shared state.
The configuration surface area is misleading: the key is accepted and stored but does nothing.

Steps to Reproduce

agents config set plan.concurrency 1
Start two long-running plan executions concurrently
Observe: both execute simultaneously — limit is not enforced
Expected: second execution queues or fails with a "concurrency limit reached" error

Fix

In plan_lifecycle_service.execute_plan(), before transitioning the plan:

Read plan.concurrency from ConfigService
Count plans currently in Execute/RUNNING or Execute/QUEUED state
If count >= limit, raise a PlanConcurrencyLimitError or queue the job (depending on spec intent)
Add an integration test scenario to features/concurrency.feature

Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: uat-tester

## Summary The `plan.concurrency` configuration key (max concurrent executing plans) is documented in the specification and registered in `ConfigService`, but no enforcement exists in the plan execution path. The setting can be written but has no runtime effect — any number of plans can execute simultaneously regardless of the configured limit. ## Evidence **Config key is defined in `config_service.py:368`:** ```python description="Maximum concurrent plan executions.", ``` **Spec documents the setting (`docs/specification.md`):** ``` plan.concurrency | integer | 4 | CLEVERAGENTS_PLAN_CONCURRENCY | Maximum number of plans that can execute concurrently. When this limit is reached, new `plan execute` commands queue until a slot opens. ``` **No enforcement found in plan execution path:** ``` $ grep -rn "plan_concurrency|plan\.concurrency|concurrency.*limit|max.*concurrent" \ src/cleveragents/application/services/plan_lifecycle_service.py \ src/cleveragents/application/services/plan_executor.py (no output) ``` The only `concurrency`-related enforcement found is inside `subplan_execution_service.py` (for *sub*plans) and `validation_pipeline.py` (for parallel validators) — neither is the top-level plan concurrency gate. ## Specification Requirement From `docs/specification.md`: > When this limit is reached, new `plan execute` commands **queue** until a slot opens. Child plans count toward the parent's concurrency allocation, not toward the global limit. This implies `execute_plan()` must check current running-plan count against `plan.concurrency` before proceeding, and either queue or reject with an appropriate error when the limit is reached. ## Impact - Users who set `agents config set plan.concurrency 1` expecting serial execution will get concurrent execution instead, causing resource contention or corrupted shared state. - The configuration surface area is misleading: the key is accepted and stored but does nothing. ## Steps to Reproduce 1. `agents config set plan.concurrency 1` 2. Start two long-running plan executions concurrently 3. Observe: both execute simultaneously — limit is not enforced 4. Expected: second execution queues or fails with a "concurrency limit reached" error ## Fix In `plan_lifecycle_service.execute_plan()`, before transitioning the plan: 1. Read `plan.concurrency` from `ConfigService` 2. Count plans currently in `Execute/RUNNING` or `Execute/QUEUED` state 3. If count >= limit, raise a `PlanConcurrencyLimitError` or queue the job (depending on spec intent) 4. Add an integration test scenario to `features/concurrency.feature` --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: uat-tester