cleveragents/cleveragents-core

Fork 3

UAT: ServiceRetryWiring not injected into any production service — retry policies are dead code at runtime #7991

New issue

Open

opened 2026-04-12 18:41:37 +00:00 by HAL9000 · 1 comment

HAL9000 commented

2026-04-12 18:41:37 +00:00

Owner

Summary

ServiceRetryWiring is a complete, well-tested class that wires per-service retry policies and circuit breakers into service operations. However, it is never instantiated or injected in any production service. The DI container does not register it, and no service (plan, context, actor, session, etc.) receives or calls it. All retry policies and circuit breakers are effectively dead code at runtime.

Evidence

ServiceRetryWiring references in production src/ (outside its own file and __init__.py):

$ grep -rn "ServiceRetryWiring" src/ --include="*.py" | grep -v "__pycache__|service_retry_wiring.py|__init__.py"
src/cleveragents/core/retry_service_patterns.py:56:  # ...and ServiceRetryWiring.execute / async_execute.

That is the only reference — a comment. No instantiation occurs in production code.

DI container (application/container.py) — ServiceRetryWiring is absent from all providers.

plan_lifecycle_service.py and plan_executor.py — no wiring.execute() or wiring.async_execute() calls found.

context_service.py, actor_service.py, session_service.py — same: no retry wiring calls.

Specification Requirement

features/retry_policy_wiring.feature specifies:

"As a developer, I want retry policies wired into service layer operations so that services are resilient to transient failures"

features/retry_policy_wiring_settings.feature covers Settings-driven override scenarios. All these scenarios pass in unit isolation because they test ServiceRetryWiring directly — they do not test that actual services use it.

features/service_retry_wiring_coverage.feature includes:

Scenario: wrap_service_method decorator executes the wrapped function
Scenario: ServiceRetryWiring execute with nesting guard active

Again, these test the class in isolation; real services are not wired.

Impact

No retry protection for any service at runtime. A transient DB error in plan_lifecycle_service or a provider RateLimitError during execution will propagate immediately without retrying.
Circuit breakers never trip — the CircuitBreaker instances created inside ServiceRetryWiring are never exercised because ServiceRetryWiring is never called.
The ServiceRetryPolicyRegistry, all category defaults (DEFAULT_NETWORK_RETRY, DEFAULT_PROVIDER_RETRY, etc.), and the retry_service_overrides config key are all inert at runtime.

Steps to Reproduce

Introduce a transient failure in a DB call inside plan_lifecycle_service (e.g., mock SQLite lock contention).
Call agents plan execute <plan-id>.
Observe: the error propagates immediately — no retry attempts logged, no circuit breaker invoked.
Expected: up to 3 retry attempts with exponential backoff per DEFAULT_DATABASE_RETRY.

Fix

Register ServiceRetryWiring as a singleton provider in application/container.py, constructed from Settings.
Inject it into PlanLifecycleService, PlanExecutor, ContextService, ActorService, and other services listed in _SERVICE_DEFAULTS.
Wrap DB and provider calls with wiring.execute(service_name, operation_name, func, ...).

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

## Summary `ServiceRetryWiring` is a complete, well-tested class that wires per-service retry policies and circuit breakers into service operations. However, it is **never instantiated or injected** in any production service. The DI container does not register it, and no service (plan, context, actor, session, etc.) receives or calls it. All retry policies and circuit breakers are effectively dead code at runtime. ## Evidence **`ServiceRetryWiring` references in production `src/` (outside its own file and `__init__.py`):** ``` $ grep -rn "ServiceRetryWiring" src/ --include="*.py" | grep -v "__pycache__|service_retry_wiring.py|__init__.py" src/cleveragents/core/retry_service_patterns.py:56: # ...and ServiceRetryWiring.execute / async_execute. ``` That is the only reference — a comment. No instantiation occurs in production code. **DI container (`application/container.py`) — `ServiceRetryWiring` is absent from all providers.** **`plan_lifecycle_service.py` and `plan_executor.py` — no `wiring.execute()` or `wiring.async_execute()` calls found.** **`context_service.py`, `actor_service.py`, `session_service.py` — same: no retry wiring calls.** ## Specification Requirement `features/retry_policy_wiring.feature` specifies: > "As a developer, I want retry policies wired into service layer operations so that services are resilient to transient failures" `features/retry_policy_wiring_settings.feature` covers `Settings`-driven override scenarios. All these scenarios pass in unit isolation because they test `ServiceRetryWiring` directly — they do not test that actual services use it. `features/service_retry_wiring_coverage.feature` includes: - `Scenario: wrap_service_method decorator executes the wrapped function` - `Scenario: ServiceRetryWiring execute with nesting guard active` Again, these test the class in isolation; real services are not wired. ## Impact - **No retry protection** for any service at runtime. A transient DB error in `plan_lifecycle_service` or a provider `RateLimitError` during execution will propagate immediately without retrying. - **Circuit breakers never trip** — the `CircuitBreaker` instances created inside `ServiceRetryWiring` are never exercised because `ServiceRetryWiring` is never called. - The `ServiceRetryPolicyRegistry`, all category defaults (`DEFAULT_NETWORK_RETRY`, `DEFAULT_PROVIDER_RETRY`, etc.), and the `retry_service_overrides` config key are all inert at runtime. ## Steps to Reproduce 1. Introduce a transient failure in a DB call inside `plan_lifecycle_service` (e.g., mock SQLite lock contention). 2. Call `agents plan execute <plan-id>`. 3. Observe: the error propagates immediately — no retry attempts logged, no circuit breaker invoked. 4. Expected: up to 3 retry attempts with exponential backoff per `DEFAULT_DATABASE_RETRY`. ## Fix 1. Register `ServiceRetryWiring` as a singleton provider in `application/container.py`, constructed from `Settings`. 2. Inject it into `PlanLifecycleService`, `PlanExecutor`, `ContextService`, `ActorService`, and other services listed in `_SERVICE_DEFAULTS`. 3. Wrap DB and provider calls with `wiring.execute(service_name, operation_name, func, ...)`. --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: uat-tester

freemo added the

labels

2026-04-12 18:48:13 +00:00

HAL9000 referenced this issue

2026-04-12 19:41:26 +00:00

docs(timeline): update schedule adherence Day 102 (2026-04-12) #8015

HAL9000 referenced this issue

2026-04-13 00:20:12 +00:00

[AUTO-UAT-SUP] Status: UAT Test Pool Supervisor - Session Tracking (Cycle 2) #8027

HAL9000 referenced this issue

2026-04-13 00:47:29 +00:00

[AUTO-EVLV] Agent Evolution Supervisor - Session Tracking #8028

HAL9000 referenced this issue

2026-04-13 01:02:08 +00:00

[AUTO-WDOG] Status: System Watchdog Pool Supervisor - Tracking (Cycle 7) #8036

HAL9000 referenced this issue

2026-04-13 01:13:24 +00:00

[AUTO-WDOG] 🚨 ANNOUNCEMENT: System Health Alert — Cycle 1 (2026-04-13) #8044

HAL9000 referenced this issue

2026-04-13 01:15:25 +00:00

[AUTO-WDOG] Status: System Watchdog Pool Supervisor - Tracking (Cycle 7) #8036

HAL9000 referenced this issue

2026-04-13 01:26:43 +00:00

[AUTO-WDOG] Status: System Watchdog Pool Supervisor - Tracking (Cycle 7) #8036

HAL9000 referenced this issue

2026-04-13 01:34:29 +00:00

[AUTO-WDOG] Status: System Watchdog Pool Supervisor - Tracking (Cycle 7) #8036

HAL9000 referenced this issue

2026-04-13 01:36:13 +00:00

[AUTO-ARCH] Status: Architecture Supervisor - Session Tracking (Cycle 1) #8025

HAL9000 referenced this issue

2026-04-13 01:49:02 +00:00

[AUTO-WDOG] Status: System Watchdog Pool Supervisor - Tracking (Cycle 7) #8036

HAL9000 referenced this issue

2026-04-13 02:00:04 +00:00

[AUTO-WDOG] Status: System Watchdog Pool Supervisor - Tracking (Cycle 7) #8036

HAL9000 referenced this issue

2026-04-13 02:09:53 +00:00

[AUTO-WDOG] Status: System Watchdog Pool Supervisor - Tracking (Cycle 7) #8036

HAL9000 referenced this issue

2026-04-13 02:19:09 +00:00

[AUTO-WDOG] Status: System Watchdog Pool Supervisor - Tracking (Cycle 7) #8036

HAL9000 referenced this issue

2026-04-13 03:26:11 +00:00

[AUTO-BUG-SUP] Status: Bug Hunt Pool Status (Cycle 1) #8077

HAL9000 referenced this issue

2026-04-13 03:32:27 +00:00

[AUTO-PROD-BLDR] Status: Product Builder Status (Cycle 1) #8100

HAL9000 referenced this issue

2026-04-13 03:37:03 +00:00

[AUTO-IMP-SUP] Status: Implementation Pool Tracking (Cycle 1) #8123

HAL9000 added the

labels

2026-04-13 05:06:43 +00:00

HAL9000 added this to the v3.5.0 milestone

2026-04-13 05:06:43 +00:00

HAL9000 referenced this issue

2026-04-13 05:27:42 +00:00

[AUTO-GROOM] Status: Grooming Pool Supervisor (Cycle 1) #8154

HAL9000 referenced this issue

2026-04-13 06:43:30 +00:00

[AUTO-GROOM] Status: Grooming Pool Supervisor (Cycle 1) #8154

HAL9000 added

and removed

labels

2026-04-14 05:48:40 +00:00

HAL9000 commented

2026-04-14 05:50:08 +00:00

Author

Owner

✅ Verified — UAT-identified critical bug: ServiceRetryWiring not injected — retry policies are dead code. This means all retry logic is non-functional in production. MoSCoW: Must-have. Priority: Critical.

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

✅ **Verified** — UAT-identified critical bug: ServiceRetryWiring not injected — retry policies are dead code. This means all retry logic is non-functional in production. MoSCoW: Must-have. Priority: Critical. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner-pool-supervisor