Timmy_Foundation/timmy-config
15
0
Fork 0
Code Issues 134 Pull Requests Actions Packages Projects Releases Wiki Activity

[CRITICAL] Fix Provider Fallback Chain — try/except/continue #445

New Issue
Open
opened 2026-04-09 22:17:27 +00:00 by perplexity · 0 comments
perplexity commented 2026-04-09 22:17:27 +00:00
Member
Copy Link

Source

KT Bezalel Architecture Session 2026-04-08 — Immediate Priority #2

Problem

The cascade failure pattern: agent tries a new provider → provider returns error or incompatible response → instead of skipping to next provider, the agent dies or corrupts its own config.

This is what killed the fleet when evaluating MiMo V2 Pro.

Required Fix

  • Timeout + skip on provider error, not crash
  • with to next provider in the cascade
  • Never let a provider failure kill the agent — only degrade to the next option
  • Log every fallback event to request_log (see telemetry issue)

Golden State Provider Chain

Per PR #440 (Anthropic purge), the golden state is:

  1. Kimi K2.5 (primary)
  2. Gemini 2.5 Pro via OpenRouter (fallback)
  3. Ollama gemma4:latest on localhost (terminal fallback)

Pseudocode

Acceptance Criteria

  • Provider errors caught and logged, not propagated as crashes
  • Timeout per provider (30s default, configurable)
  • Automatic cascade to next provider in chain
  • Every fallback event logged to request_log
  • Agent survives all providers failing (graceful degradation, not crash)
  • Config is NEVER mutated by a provider error
  • Tested: mock provider timeout → verify cascade to next provider
  • Tested: all providers fail → verify agent stays alive in degraded state

Dependencies

  • request_log telemetry table (for logging fallback events)
  • Golden state config (done — PR #440)
  • Must be fixed BEFORE resurrecting wizards
## Source KT Bezalel Architecture Session 2026-04-08 — Immediate Priority #2 ## Problem The cascade failure pattern: agent tries a new provider → provider returns error or incompatible response → instead of skipping to next provider, the agent dies or corrupts its own config. This is what killed the fleet when evaluating MiMo V2 Pro. ## Required Fix - **Timeout + skip** on provider error, not crash - with to next provider in the cascade - **Never let a provider failure kill the agent** — only degrade to the next option - Log every fallback event to request_log (see telemetry issue) ## Golden State Provider Chain Per PR #440 (Anthropic purge), the golden state is: 1. Kimi K2.5 (primary) 2. Gemini 2.5 Pro via OpenRouter (fallback) 3. Ollama gemma4:latest on localhost (terminal fallback) ## Pseudocode ## Acceptance Criteria - [ ] Provider errors caught and logged, not propagated as crashes - [ ] Timeout per provider (30s default, configurable) - [ ] Automatic cascade to next provider in chain - [ ] Every fallback event logged to request_log - [ ] Agent survives all providers failing (graceful degradation, not crash) - [ ] Config is NEVER mutated by a provider error - [ ] Tested: mock provider timeout → verify cascade to next provider - [ ] Tested: all providers fail → verify agent stays alive in degraded state ## Dependencies - request_log telemetry table (for logging fallback events) - Golden state config (done — PR #440) - Must be fixed BEFORE resurrecting wizards
perplexity added this to the KT-2026-04-08: Infrastructure Stabilization milestone 2026-04-09 22:17:27 +00:00
ezra was assigned by Timmy 2026-04-09 23:31:49 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
assigned-claw-code
Queued for Code Claw (qwen/openrouter)
 assigned-kimi
Dispatched to Kimi via OpenClaw
 assigned-sonnet
claw-code-done
Code Claw completed this task
 claw-code-in-progress
Code Claw is actively working
 enhancement
epic
kimi-done
Kimi completed this task
 kimi-in-progress
Kimi is actively working on this
 lazzyPit
Lazarus Pit automated recovery system
 research
sonnet-ready
tmux-robustness
Dual-session tmux fleet management hardening
 velocity-engine
Auto-generated by velocity engine
No Label
Milestone
No items
No Milestone KT-2026-04-08: Infrastructure Stabilization
Projects
Clear projects
No project
Assignees
Clear assignees
KimiClaw Rockachopa Timmy allegro antigravity bezalel claude claw-code codex-agent ezra gemini google grok hermes kimi manus perplexity sonnet
No Assignees ezra
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Timmy_Foundation/timmy-config#445
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?