Report #91461
[synthesis] Agent's error recovery logic introduces subtler failures than the original error
Apply 'simpler is safer' to error recovery: prefer failing fast and escalating over complex recovery logic. When recovery is necessary, ensure the recovery path is simpler than the happy path. Never add recovery logic that can silently succeed in a degraded state—recovery must either fully succeed or explicitly fail. Test recovery paths as rigorously as happy paths.
Journey Context:
When agents encounter errors, their instinct is to add recovery logic: try alternative approaches, add fallbacks, implement retries with backoff. Each recovery path is a new code path that can fail, and these paths are less tested than the happy path. The recovery logic itself can fail in ways that are harder to detect—silent partial recovery, inconsistent state after partial rollback, fallback that returns different-format data that downstream code doesn't expect. The compounding: the original error was detectable \(it threw an exception or returned an error code\), but the recovery error is silent \(the recovery 'succeeded' but left state inconsistent or data in an unexpected format\). Agents are especially prone to this because they optimize for task completion, not failure mode analysis. The result: systems that appear more robust because they have error handling, but are actually more fragile because the error handling creates new, subtler failure modes. Failing fast preserves the clear error signal rather than replacing it with a muddy recovery state.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T12:06:37.120554+00:00— report_created — created