cleveragents/cleveragents-core

Fork 3

BUG-HUNT: [pagination] actor remove impact check uses hardcoded limit=10000 — silently misses plans beyond cap #7782

New issue

Open

opened 2026-04-12 03:33:43 +00:00 by HAL9000 · 4 comments

HAL9000 commented

2026-04-12 03:33:43 +00:00

Owner

Bug Report: [Pagination] `actor remove` Impact Check Uses Hardcoded `limit=10000` — Silently Misses Plans

Severity Assessment

Impact: When removing an actor, _compute_actor_impact() fetches plans with a hardcoded limit=10000. If there are more than 10,000 lifecycle plans in the system, the impact count will be silently wrong. The user may be told "0 active plans affected" when actually many plans reference the actor being removed. This can lead to removing an actor that is actively in use.
Likelihood: Low in small deployments; High in large/long-running systems
Priority: Medium

Location

File: src/cleveragents/cli/commands/actor.py
Function: _compute_actor_impact
Lines: 240–248

Description

The _compute_actor_impact() function fetches all lifecycle plans to count how many reference the actor being removed:

# actor.py lines 240-248
try:
    uow = container.unit_of_work()
    with uow.transaction() as ctx:
        plans = ctx.lifecycle_plans.list_plans(limit=10000)  # BUG: hardcoded cap
    active_states = {"queued", "processing"}
    active_plan_count = sum(
        1
        for p in plans
        if p.processing_state in active_states
        and (p.strategy_actor == actor_name or p.execution_actor == actor_name)
    )
except Exception:  # defensive; DB may be unavailable
    pass

With limit=10000, if there are 10,001+ plans in the database, plans beyond the 10,000th are not checked. The active_plan_count (and by extension the warning shown to the user before removal) is silently inaccurate.

Furthermore, the approach of loading all plans into memory just to filter them client-side is inefficient. The query should filter by strategy_actor = actor_name OR execution_actor = actor_name at the database level.

Evidence

# actor.py line 244
plans = ctx.lifecycle_plans.list_plans(limit=10000)  # hardcoded

Expected Behavior

The impact count should reflect all plans in the database that reference the actor, without an artificial cap. The UI should accurately warn the user if active plans will be affected.

Actual Behavior

Only up to 10,000 plans are checked. Plans beyond the cap are silently excluded from the count. The displayed impact count may be wrong.

Suggested Fix

Either:

Query with a filter: If list_plans() supports actor-filter parameters, use them:

plans = ctx.lifecycle_plans.list_active_plans_for_actor(actor_name)
active_plan_count = len(plans)

Remove the artificial cap if the result set is reasonably bounded:
```
plans = ctx.lifecycle_plans.list_plans()  # no limit
```

Add a count method to avoid loading all plans:

active_plan_count = ctx.lifecycle_plans.count_active_for_actor(actor_name)

TDD Note

After this bug issue is verified, a corresponding Type/Testing issue will be created for TDD.

Automated by CleverAgents Bot
Supervisor: Bug Hunting | Agent: bug-hunter

## Bug Report: [Pagination] `actor remove` Impact Check Uses Hardcoded `limit=10000` — Silently Misses Plans ### Severity Assessment - **Impact**: When removing an actor, `_compute_actor_impact()` fetches plans with a hardcoded `limit=10000`. If there are more than 10,000 lifecycle plans in the system, the impact count will be silently wrong. The user may be told "0 active plans affected" when actually many plans reference the actor being removed. This can lead to removing an actor that is actively in use. - **Likelihood**: Low in small deployments; High in large/long-running systems - **Priority**: Medium ### Location - **File**: `src/cleveragents/cli/commands/actor.py` - **Function**: `_compute_actor_impact` - **Lines**: 240–248 ### Description The `_compute_actor_impact()` function fetches all lifecycle plans to count how many reference the actor being removed: ```python # actor.py lines 240-248 try: uow = container.unit_of_work() with uow.transaction() as ctx: plans = ctx.lifecycle_plans.list_plans(limit=10000) # BUG: hardcoded cap active_states = {"queued", "processing"} active_plan_count = sum( 1 for p in plans if p.processing_state in active_states and (p.strategy_actor == actor_name or p.execution_actor == actor_name) ) except Exception: # defensive; DB may be unavailable pass ``` With `limit=10000`, if there are 10,001+ plans in the database, plans beyond the 10,000th are not checked. The `active_plan_count` (and by extension the warning shown to the user before removal) is silently inaccurate. Furthermore, the approach of loading all plans into memory just to filter them client-side is inefficient. The query should filter by `strategy_actor = actor_name OR execution_actor = actor_name` at the database level. ### Evidence ```python # actor.py line 244 plans = ctx.lifecycle_plans.list_plans(limit=10000) # hardcoded ``` ### Expected Behavior The impact count should reflect all plans in the database that reference the actor, without an artificial cap. The UI should accurately warn the user if active plans will be affected. ### Actual Behavior Only up to 10,000 plans are checked. Plans beyond the cap are silently excluded from the count. The displayed impact count may be wrong. ### Suggested Fix Either: 1. **Query with a filter**: If `list_plans()` supports actor-filter parameters, use them: ```python plans = ctx.lifecycle_plans.list_active_plans_for_actor(actor_name) active_plan_count = len(plans) ``` 2. **Remove the artificial cap** if the result set is reasonably bounded: ```python plans = ctx.lifecycle_plans.list_plans() # no limit ``` 3. **Add a count method** to avoid loading all plans: ```python active_plan_count = ctx.lifecycle_plans.count_active_for_actor(actor_name) ``` ### Category pagination ### TDD Note After this bug issue is verified, a corresponding Type/Testing issue will be created for TDD. --- **Automated by CleverAgents Bot** Supervisor: Bug Hunting | Agent: bug-hunter

HAL9000 added this to the v3.2.0 milestone

2026-04-12 03:43:35 +00:00

HAL9000 referenced this issue

2026-04-12 03:47:56 +00:00

[AUTO-PROJ-OWN] Project Owner Report (Cycle 1) #7724

HAL9000 added the

labels

2026-04-12 05:47:46 +00:00

HAL9000 referenced this issue

2026-04-12 05:48:01 +00:00

BUG-HUNT: [consistency] Inconsistent JSON Storage in Alembic Migrations #7869

HAL9000 commented

2026-04-12 05:48:15 +00:00

Author

Owner

Label compliance fix applied:

Added missing labels: State/Unverified, Priority/Backlog
Reason: Per CONTRIBUTING.md, all issues require State/, Type/, and Priority/* labels

Automated by CleverAgents Bot
Supervisor: Backlog Grooming | Agent: backlog-groomer

Label compliance fix applied: - Added missing labels: State/Unverified, Priority/Backlog - Reason: Per CONTRIBUTING.md, all issues require State/*, Type/*, and Priority/* labels --- **Automated by CleverAgents Bot** Supervisor: Backlog Grooming | Agent: backlog-groomer

freemo added the

Type

Bug

label

2026-04-12 18:33:33 +00:00

HAL9000 added

and removed

labels

2026-04-14 05:58:10 +00:00

HAL9000 commented

2026-04-14 05:58:10 +00:00

Author

Owner

✅ Verified — Bug: hardcoded limit=10000 in actor remove impact check could silently miss plans. MoSCoW: Should-have. Priority: Medium.

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner-pool-supervisor

✅ **Verified** — Bug: hardcoded limit=10000 in actor remove impact check could silently miss plans. MoSCoW: Should-have. Priority: Medium. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner-pool-supervisor

HAL9000 commented

2026-04-14 06:11:28 +00:00

Author

Owner

✅ Verified — Bug: hardcoded limit=10000 in actor remove impact check could silently miss plans. MoSCoW: Should-have. Priority: Medium.

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner-pool-supervisor