fix(failover): classify upstream_error as server_error to trigger model fallback#96110
fix(failover): classify upstream_error as server_error to trigger model fallback#96110whiteyzy wants to merge 1 commit into
Conversation
…model fallback When a provider returns an error with type:upstream_error (e.g. OpenAI responses API), classifyFailoverSignal returns null because the errorType is not recognized, so model fallback never triggers and the turn ends with 'LLM request failed.' Add upstream_error → server_error classification in classifyFailoverSignal so configured fallback models are attempted on transient provider-side failures. Closes openclaw#95519.
|
Thanks for the context here. I swept through the related work, and this is now duplicate or superseded. Close: this PR is superseded by the merged canonical fix in #95542, and current main now covers both the helper-level Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Canonical path: #95542 merged and landed the fuller fix for #95519, including both assistant error classification and embedded result-classifier coverage. So I’m closing this here and keeping the remaining discussion on #95542 and #95519. Review detailsBest possible solution: Keep #95542 as the canonical landed fix and close this conflicting duplicate branch. Do we have a high-confidence way to reproduce the issue? No current-main failure reproduction remains. The linked bug was source-reproducible before, but current main now maps Is this the best way to solve the issue? No. The helper-only patch was a plausible partial fix when opened, but the merged current-main fix is better because it covers both the helper and embedded result-classifier boundaries. Security review: Security review cleared: The PR only changes internal TypeScript fallback classification and tests; it does not touch dependencies, workflows, secrets, package scripts, or supply-chain surfaces. AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against 6cb82eaab865; fix evidence: commit cfd8ba8fc81d, main fix timestamp 2026-06-29T14:12:09+03:00. |
clawsweeper
Bot
added
rating: 🧂 unranked krab
|
ClawSweeper applied the proposed close for this PR.
|
1 participant
Summary
Fixes #95519: When a provider returns
{"error":{"type":"upstream_error","message":"Upstream request failed"}}, model fallback does not trigger becauseclassifyFailoverSignaldoes not recognize theupstream_errorerrorType. The turn ends with "LLM request failed." instead of trying configured fallback models.Fix: In
classifyFailoverSignal, classifyerrorType === "upstream_error"asserver_errorbefore falling through to message-based classification. This triggers model fallback for transient provider-side failures.Real behavior proof
classifyFailoverSignal({errorType: "upstream_error", ...})returns{kind: "reason", reason: "server_error"}— upstream_error is now recognized as a transient failure eligible for model fallback.Tests and validation
Which commands did you run?
node scripts/run-vitest.mjs run src/agents/embedded-agent-helpers/errors.test.ts # 7 passed (1 test file, 2 new tests added)What regression coverage was added?
"classifies upstream_error errorType as server_error for model fallback (regression for #95519)"— verifies upstream_error → server_error"does not classify unhandled error messages as server_error"— verifies no false positivesRisk checklist
Did user-visible behavior change? Yes — upstream_error now triggers model fallback instead of ending the turn immediately.
Did config, environment, or migration behavior change? No
Did security, auth, secrets, network, or tool execution behavior change? No
What is the highest-risk area? Could cause fallback loops if upstream_error is persistent across all models. Mitigation: existing fallback exhaustion logic already handles retry loops.
Closes #95519.
🤖 Generated with Claude Code
Co-Authored-By: Claude Code [email protected]