fix(agents): classify missing_tool_result as tool_error to prevent cross-provider failover#95488
Conversation
|
Thanks for the context here. I swept through the related work, and this is now duplicate or superseded. Close as superseded: this PR targets the same linked missing-tool-result fallback bug as the open, proof-positive sibling PR, but its Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Canonical path: Let #95543 remain the canonical implementation path if maintainers agree, because it uses the existing non-provider abort boundary and includes runtime-boundary proof. So I’m closing this here and keeping the remaining discussion on #95543. Review detailsBest possible solution: Let #95543 remain the canonical implementation path if maintainers agree, because it uses the existing non-provider abort boundary and includes runtime-boundary proof. Do we have a high-confidence way to reproduce the issue? Yes at source level: current main synthesizes Is this the best way to solve the issue? No: this branch classifies the sentinel as a new failover reason, but current decision code still treats concrete non-timeout failover reasons as profile-rotation/model-fallback candidates. The better fix is a narrow local non-provider abort guard with provider-metadata precedence tests. Security review: Security review cleared: The diff changes TypeScript error classification/type unions only; no dependency, CI, secret, permission, install, or supply-chain surface changed. AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against 4fc504d321b6. |
…oss-provider failover When a local tool execution fails (e.g. hung bash → missing_tool_result), the error was classified as 'unclassified' which triggers cross-provider model fallback. A hung local command is not a model/provider fault, so switching providers cannot remedy it. Add 'tool_error' FailoverReason and classify any error message containing 'missing_tool_result' as tool_error. This prevents the failover engine from silently switching the user's model mid-conversation. Fixes openclaw#95474 Co-Authored-By: Claude <[email protected]>
Co-Authored-By: Claude <[email protected]>
4c67386 to
0db873a
Compare
|
ClawSweeper applied the proposed close for this PR.
|
What Problem This Solves
When a local tool execution fails (e.g. hung
bash→missing_tool_result), the error was classified asunclassifiedwhich triggers cross-provider model fallback. A hung local command is not a model/provider fault, so switching providers cannot remedy it — the user sees the model bounce between providers with no benefit.Add
tool_erroras a newFailoverReasonand detectmissing_tool_resultin error classification to prevent cross-provider failover.Fixes #95474.
Change
embedded-agent-helpers/types.ts"tool_error"toFailoverReasonunionembedded-agent-helpers/errors.tsmissing_tool_resultinclassifyFailoverClassificationFromMessageandclassifyProviderRuntimeFailureKindfailover-policy.tstool_errortoshouldPreserveTransientCooldownProbeSlot(non-failover)auth-profiles/types.ts"tool_error"toAuthProfileFailureReasonruntime-plan/types.ts"tool_error"toAgentRuntimeFailoverReasonEvidence
embedded-agent-helpers.isbillingerrormessage.test.tsruntime-plan/types.compat.test.tsRisk
tool_erroris treated as non-transient — no cooldown probe, no cross-provider failovershouldPreserveTransientCooldownProbeSlotguard ensures fallback loop does not advance to next candidate fortool_error🤖 Generated with Claude Code