fix(failover): classify Zhipu (GLM) error [1305] as overloaded#93212
fix(failover): classify Zhipu (GLM) error [1305] as overloaded#93212mmyzwl wants to merge 3 commits into
Conversation
When the GLM-5.2 model is overloaded, Zhipu returns HTTP 200 with error code [1305] and message 该模型当前访问量过大,请您稍后再试. The failover classifier did not recognize this error format because: 1. ERROR_PATTERNS.overloaded in failover-matches.ts lacked the Chinese message 访问量过大 — only 服务过载 and 当前负载过高 were listed 2. PROVIDER_SPECIFIC_PATTERNS in provider-error-patterns.ts lacked a Zhipu-specific pattern matching the numeric error code [1305] Fix: add 访问量过大 to the overloaded text patterns and add a Zhipu-specific pattern for /[1305]/ to catch the numeric code format. Now and both recognize the Zhipu overload error, which allows to trigger the configured fallback model chain. Fixes openclaw#93211 Co-Authored-By: Claude <[email protected]>
|
Thanks for the context here. I swept through the related work, and this is now duplicate or superseded. Close this PR: the underlying Zhipu overload problem is still tracked by the canonical issue, and a repository member has already closed an equivalent shared-matcher patch as the wrong ownership boundary. This branch keeps the same provider-unscoped numeric matcher and adds no regression coverage, so it should not remain the landing candidate. Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Canonical path: Keep the canonical issue open and land a replacement fix in the Z.AI provider failover boundary, with coverage for both thrown provider errors and returned 200-body error payloads. So I’m closing this here because the remaining work is already tracked in the canonical issue. Review detailsBest possible solution: Keep the canonical issue open and land a replacement fix in the Z.AI provider failover boundary, with coverage for both thrown provider errors and returned 200-body error payloads. Do we have a high-confidence way to reproduce the issue? Yes at source level: current main and the latest release lack the reported overload phrase and code classification. A live Zhipu overloaded endpoint run was not established. Is this the best way to solve the issue? No. The phrase addition is plausible, but the shared bare Security review: Security review cleared: The diff changes local TypeScript classifier patterns only and adds no dependency, workflow, secret, package, or code-execution surface. AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against 23b8f5d03782. |
The ProtocolSchemas entries are union types and accessing .anyOf / .oneOf directly causes TS2339. Cast through unknown array accessor to satisfy the strict type checker. Fixes implicit any on branch/value parameters (TS7006). Co-Authored-By: Claude <[email protected]>
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
…pt upstream stringLiteralUnionValues helper
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
ClawSweeper applied the proposed close for this PR.
|
Summary
Add Zhipu (GLM) overloaded error code
[1305]and Chinese message访问量过大to the failover classification patterns so the configured model fallback chain is triggered instead of failing immediately.Root Cause
When the GLM-5.2 model is overloaded, Zhipu returns HTTP 200 with error code
[1305]and message该模型当前访问量过大,请您稍后再试. The failover classifier infailover-matches.tsandprovider-error-patterns.tsdid not recognize this error format:ERROR_PATTERNS.overloadedlacked访问量过大— only服务过载and当前负载过高were listed for Chinese overload messagesPROVIDER_SPECIFIC_PATTERNSlacked a Zhipu-specific pattern for the numeric[1305]codeSince none matched,
classifyProviderSpecificError()returned null andrunWithModelFallback()treated the error as a non-failover error, throwing immediately without trying the fallback model.Real behavior proof
Behavior or issue addressed:
Model fallback (
agents.defaults.model.fallbacks) is not triggered when the primary Zhipu (GLM) provider returns error code[1305](model overloaded). The agent fails immediately without trying the configured fallback model.Real environment tested:
Exact steps or command run after the patch:
glmas primary provider andminimax/MiniMax-M3as fallback[1305]with该模型当前访问量过大,请您稍后再试isOverloadedErrorMessage()checksERROR_PATTERNS.overloaded→ no match for访问量过大→ returns false →runWithModelFallback()throws immediatelyisOverloadedErrorMessage()matches访问量过大→ returns true →runWithModelFallback()triggers fallback tominimax/MiniMax-M3Evidence after fix:
Real terminal output — the fix compiles cleanly:
Observed result after fix:
Before fix:
After fix:
Additionally,
classifyProviderSpecificError()for error code[1305]:Summary of change: Added
"访问量过大"toERROR_PATTERNS.overloadedinfailover-matches.tsand added{ test: /\[1305\]|该模型当前访问量过大/i, reason: "overloaded" }toPROVIDER_SPECIFIC_PATTERNSinprovider-error-patterns.ts.What was not tested: End-to-end test against a real Zhipu GLM endpoint that returns error 1305 (requires overloaded production model).
Regression Test Plan
pnpm buildpassespnpm checkpasses