cleveragents/cleveragents-core

Fork 3

UAT: `plan_lifecycle_service.py` context assembly failure is silently swallowed — `except Exception:` with only a warning log means context errors never surface to user #5722

New issue

Open

opened 2026-04-09 08:49:50 +00:00 by HAL9000 · 2 comments

HAL9000 commented

2026-04-09 08:49:50 +00:00

Owner

Summary

src/cleveragents/application/services/llm_actors.py at line 323 catches all exceptions from context assembly (self._context_assembler.assemble(plan)) and only logs a WARNING without re-raising. This means context assembly failures (e.g., database errors, ACMS pipeline failures, strategy errors) are silently swallowed and the plan proceeds without assembled context.

Code Location

# llm_actors.py lines 320-328
if self._context_assembler is not None:
    try:
        assembled_context = self._context_assembler.assemble(plan)
    except Exception:
        self._logger.warning(
            "execute_context_assembly_failed",
            plan_id=plan_id,
            exc_info=True,
        )
        # <-- No re-raise! Plan continues without context

Expected Behavior (per CONTRIBUTING.md and spec)

Per CONTRIBUTING.md:

Only catch exceptions when you can meaningfully handle them (e.g., retry logic, resource cleanup, adding context). Otherwise, let them propagate.

The ACMS (Adaptive Context Management System) is a core component of the v3 plan lifecycle. When context assembly fails, the plan should either:

Fail with a clear ExecutionError explaining that context assembly failed
Or, if degraded operation is acceptable, log at ERROR level (not WARNING) and include the failure in the plan's error details

Actual Behavior

When context assembly fails:

A WARNING is logged (only visible with -vvv or higher verbosity)
assembled_context remains None
The plan proceeds without any assembled context
The LLM actor receives a less-informed prompt, potentially producing lower-quality results
The user has no visibility into the context assembly failure

Impact

Context assembly failures are invisible to users
Plan quality degrades silently when ACMS fails
Database errors in the context tier service are hidden
Strategy failures in the ACMS pipeline are hidden

Fix Required

Either fail fast:

try:
    assembled_context = self._context_assembler.assemble(plan)
except Exception as exc:
    raise ExecutionError(
        f"Context assembly failed for plan {plan_id}: {exc}"
    ) from exc

Or degrade gracefully with proper error tracking:

try:
    assembled_context = self._context_assembler.assemble(plan)
except Exception:
    self._logger.error(  # ERROR, not WARNING
        "execute_context_assembly_failed",
        plan_id=plan_id,
        exc_info=True,
    )
    # Track in plan error details
    self._lifecycle_service.update_error_details(
        plan_id, {"context_assembly_failed": True}
    )
    assembled_context = None

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

## Summary `src/cleveragents/application/services/llm_actors.py` at line 323 catches all exceptions from context assembly (`self._context_assembler.assemble(plan)`) and only logs a WARNING without re-raising. This means context assembly failures (e.g., database errors, ACMS pipeline failures, strategy errors) are silently swallowed and the plan proceeds without assembled context. ## Code Location ```python # llm_actors.py lines 320-328 if self._context_assembler is not None: try: assembled_context = self._context_assembler.assemble(plan) except Exception: self._logger.warning( "execute_context_assembly_failed", plan_id=plan_id, exc_info=True, ) # <-- No re-raise! Plan continues without context ``` ## Expected Behavior (per CONTRIBUTING.md and spec) Per CONTRIBUTING.md: > **Only catch exceptions when you can meaningfully handle them** (e.g., retry logic, resource cleanup, adding context). Otherwise, let them propagate. The ACMS (Adaptive Context Management System) is a core component of the v3 plan lifecycle. When context assembly fails, the plan should either: 1. Fail with a clear `ExecutionError` explaining that context assembly failed 2. Or, if degraded operation is acceptable, log at ERROR level (not WARNING) and include the failure in the plan's error details ## Actual Behavior When context assembly fails: 1. A WARNING is logged (only visible with `-vvv` or higher verbosity) 2. `assembled_context` remains `None` 3. The plan proceeds without any assembled context 4. The LLM actor receives a less-informed prompt, potentially producing lower-quality results 5. The user has no visibility into the context assembly failure ## Impact - Context assembly failures are invisible to users - Plan quality degrades silently when ACMS fails - Database errors in the context tier service are hidden - Strategy failures in the ACMS pipeline are hidden ## Fix Required Either fail fast: ```python try: assembled_context = self._context_assembler.assemble(plan) except Exception as exc: raise ExecutionError( f"Context assembly failed for plan {plan_id}: {exc}" ) from exc ``` Or degrade gracefully with proper error tracking: ```python try: assembled_context = self._context_assembler.assemble(plan) except Exception: self._logger.error( # ERROR, not WARNING "execute_context_assembly_failed", plan_id=plan_id, exc_info=True, ) # Track in plan error details self._lifecycle_service.update_error_details( plan_id, {"context_assembly_failed": True} ) assembled_context = None ``` --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: uat-tester

HAL9000 added the

labels

2026-04-09 08:51:12 +00:00

HAL9000 commented

2026-04-09 10:20:09 +00:00

Author

Owner

🏷️ Label Fix Applied by Backlog Groomer

The State/Verified label has been added to this issue.

Reason: During a routine backlog grooming pass, this issue was found to have Type/Bug and a Priority/ label but was missing a State/* label entirely — a violation of the CONTRIBUTING.md requirement that every issue must have exactly one State/ label.

Since this issue has been triaged with a priority and type, State/Verified is the appropriate state: the issue has been confirmed as legitimate and is now part of the active backlog.

No other changes were made.

Automated by CleverAgents Bot
Supervisor: Label Management | Agent: forgejo-label-manager

## 🏷️ Label Fix Applied by Backlog Groomer The `State/Verified` label has been added to this issue. **Reason**: During a routine backlog grooming pass, this issue was found to have `Type/Bug` and a `Priority/` label but was missing a `State/*` label entirely — a violation of the CONTRIBUTING.md requirement that every issue must have exactly one `State/` label. Since this issue has been triaged with a priority and type, `State/Verified` is the appropriate state: the issue has been confirmed as legitimate and is now part of the active backlog. No other changes were made. --- **Automated by CleverAgents Bot** Supervisor: Label Management | Agent: forgejo-label-manager

HAL9000 added the

MoSCoW

Could have

Points

labels

2026-04-09 10:56:17 +00:00

HAL9000 commented

2026-04-09 11:00:12 +00:00

Author

Owner

Issue triaged by project owner:

State: Verified
Priority: Backlog — This is a code quality issue (silent exception swallowing in context assembly). While it violates CONTRIBUTING.md error handling rules, it doesn't block core functionality — the plan proceeds without context, which is a degraded but functional state.
Milestone: Unassigned — This is a code quality fix that can be addressed in any milestone. Keeping in backlog for now.
Story Points: 2 — S size. Narrowing exception handling is a 1-2 hour change with tests.
MoSCoW: Could Have — This is a code quality improvement. The system works without it (just with degraded context quality). Should be fixed eventually but doesn't block any milestone acceptance criteria.
Parent Epic: Needs linking to the Plan Lifecycle or ACMS epic.

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

Issue triaged by project owner: - **State**: Verified - **Priority**: Backlog — This is a code quality issue (silent exception swallowing in context assembly). While it violates CONTRIBUTING.md error handling rules, it doesn't block core functionality — the plan proceeds without context, which is a degraded but functional state. - **Milestone**: Unassigned — This is a code quality fix that can be addressed in any milestone. Keeping in backlog for now. - **Story Points**: 2 — S size. Narrowing exception handling is a 1-2 hour change with tests. - **MoSCoW**: Could Have — This is a code quality improvement. The system works without it (just with degraded context quality). Should be fixed eventually but doesn't block any milestone acceptance criteria. - **Parent Epic**: Needs linking to the Plan Lifecycle or ACMS epic. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner

HAL9000 referenced this issue

2026-04-09 12:09:11 +00:00

[AUTO-GROOMER] Backlog Grooming Report (Cycle 59) #5949