Repository navigation
Turn-failed card shows the LAST fallback rung's error ('Connection error') and hides the primary failure (a 400) #4084
Description
Summary
When a turn exhausts its fallback chain, the turn-failed card's technical details show the error from the LAST rung tried, not the primary failure. In a real user report (desktop, Opus via the Claude subscription), the engine log shows the primary model failing with API Error: 400 You're out of extra usage…. The chain then moved through claude-opus-5 to a different provider's claude-opus-5, which failed with Connection error.. The card showed only "Provider error … Connection error.", so the user (and our triage) chased a network problem that didn't exist.
Expected
The card's details lead with the primary model's error, the one that started the fallback walk, and list the other rungs' errors as secondary ("then: kiro/claude-opus-5 → Connection error"). A distinct failure class on the primary (a billing/usage 400) is never hidden behind a later rung's generic error.
Acceptance
- A test: a chain where the primary fails with a 400 usage error and the last rung fails with a connection error. The card/model shows the 400 first, with the other rungs listed.
- The provider error presentation (desktop
providerFailurePresentation.tsand senpi's fallback summary) agrees on which error is primary.
Related: senpi#4083 (a duplicate same-name rung in the same chain).
Activity
code-yeongyu commentedon Oct 23, 2026
Acceptance detail (from a real report, sanitized): the engine log sequence was
anthropic-subscription/claude-opus-5-5→ 400 'out of extra usage', thenanthropic-subscription/claude-opus-5→ the same 400, thenkiro/claude-opus-5→ 'Connection error.' ×5, andcandidates_exhausted. The card showed only 'Connection error.' RED: replay exactly this sequence through the fallback summary/presentation, and assert the card leads with the primary 400 and lists the later rungs as detail.code-yeongyu commentedon Oct 26, 2026
Linked user report (desktop, 2026.1025.3, Anthropic subscription via OAuth): still failing after reinstall; the desktop provider list also shows an undeletable 'kiro' provider that requests seem to go to (sisyphuslabs/omo-desktop-app#4711). If 'kiro' is a fallback rung in that user's chain, the 'Connection error' shown would be the last rung's failure (this issue's class), not the Claude account's.