Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Fallback model does not trigger for api_error responses with non-standard message text (e.g. MiniMax 520) [4 pull requests, 4 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#49440•Fetched 2026-04-08 00:55:18
View on GitHub
Comments
4
Participants
3
Timeline
19
Reactions
0
Author
d19550408-afkd19550408-afk
Participants
d19550408-afkd19550408-afkHollychou924Hollychou924RyceRyce
Timeline (top)
referenced ×8cross-referenced ×5commented ×2labeled ×2

Bug: Fallback model does not trigger for api_error responses with non-standard message text (e.g. MiniMax 520) Type: Bug Severity: High — primary model failures surface directly to users; configured fallback is silently ignored Affected version: (current as of 2026-03-18) Component: Error classification / model failover (reply-Bm8VrLQh.js)

Summary When a provider returns an Anthropic-compatible api_error response with a non-standard message string (e.g. "unknown error, 520 (1000)"), OpenClaw's isJsonApiInternalServerError() function returns false because it requires the message to contain "internal server error". This prevents fallback from triggering.

Root Cause In reply-Bm8VrLQh.js, isJsonApiInternalServerError():

javascriptCopyCopied! function isJsonApiInternalServerError(raw) { const value = raw.toLowerCase(); return value.includes(""type":"api_error"") && value.includes("internal server error"); } MiniMax's 520 error body:

JSON "unknown error" ≠ "internal server error" → fallback never triggers.

Proposed Fix javascriptCopyCopied! function isJsonApiInternalServerError(raw) { const value = raw.toLowerCase(); return value.includes(""type":"api_error""); } Workaround Patch the dist file directly — lost on npm upgrade openclaw.

Error Message

Component: Error classification / model failover (reply-Bm8VrLQh.js) When a provider returns an Anthropic-compatible api_error response with a non-standard message string (e.g. "unknown error, 520 (1000)"), OpenClaw's isJsonApiInternalServerError() function returns false because it requires the message to contain "internal server error". This prevents fallback from triggering. return value.includes(""type":"api_error"") && value.includes("internal server error"); MiniMax's 520 error body: "unknown error" ≠ "internal server error" → fallback never triggers. You must be utilizing MiniMax as a service provider and they have some sort of server error. Not deterministically repeatable. The proposed fix generalizes the error handling such that the fallback model is called with any type of API error. Correct behavior if API error from MiniMax.io service to move to fallback model API error reported to user interface but main agent was not responding

Root Cause

Summary When a provider returns an Anthropic-compatible api_error response with a non-standard message string (e.g. "unknown error, 520 (1000)"), OpenClaw's isJsonApiInternalServerError() function returns false because it requires the message to contain "internal server error". This prevents fallback from triggering.

Fix Action

Fix / Workaround

Proposed Fix javascriptCopyCopied! function isJsonApiInternalServerError(raw) { const value = raw.toLowerCase(); return value.includes(""type":"api_error""); } Workaround Patch the dist file directly — lost on npm upgrade openclaw.

PR fix notes

PR #49462: fix: trigger model fallback for all api_error responses

Description (problem / solution / changelog)

Problem\n\nThe function required BOTH AND in the response text. Providers like MiniMax return api_error with non-standard messages (e.g. ), causing the fallback model to silently never trigger.\n\n## Fix\n\nRemoved the text requirement. Any response with is by definition a provider-side failure and should trigger fallback regardless of the message text.\n\nFixes #49440\n\n## Testing\n\nNo existing tests for this function. The fix is a one-line condition removal — any api_error is a provider error by definition.

Changed files

  • src/agents/pi-embedded-helpers/errors.ts (modified, +3/-3)
  • src/agents/session-transcript-repair.ts (modified, +4/-1)

PR #49486: fix: generalize api_error detection for fallback model triggering

Description (problem / solution / changelog)

Summary

isJsonApiInternalServerError() previously required both "type":"api_error" and the text "internal server error" to classify an error as retryable/fallback-eligible. This caused fallback models to never trigger for providers that use non-standard error messages.

Problem

MiniMax (and potentially other non-Anthropic providers) returns api_error with different message text:

{"type":"api_error","message":"unknown error, 520 (1000)"}

The old check required "internal server error" in the message, so this was not classified as a retryable error, and the configured fallback model was never used.

Fix

Remove the message text requirement. Any response with "type":"api_error" is by definition a provider-side failure — the specific message text is irrelevant to the fallback decision.

Before:

return value.includes(type:api_error) && value.includes("internal server error");

After:

return value.includes(type:api_error);

Risk

Low. The api_error type is defined as a provider-side transient failure. Triggering fallback on all such errors (rather than just those with a specific English message) is the correct, provider-agnostic behavior.

Fixes #49440

Changed files

  • src/agents/pi-embedded-helpers/errors.ts (modified, +9/-4)

PR #49506: fix: allow fallback model for any api_error type (Issue #49440)

Description (problem / solution / changelog)

Summary

Fixes Issue #49440: Fallback model does not trigger for api_error responses with non-standard message text (e.g. MiniMax 520).

Root Cause

The isJsonApiInternalServerError() function in src/agents/pi-embedded-helpers/errors.ts required BOTH conditions:

  1. "type":"api_error"
  2. "internal server error"

But providers like MiniMax return different error messages (e.g., "unknown error, 520 (1000)"), so the fallback never triggers.

Fix

Removed the "internal server error" check - now only checks for any api_error type to trigger the fallback model.

Testing

  • Build passes: pnpm build --filter=agents
  • Manual verification: The function now returns true for any api_error type regardless of message text

AI-ASSISTED

This fix was developed with AI assistance (Atlas).

Changed files

  • src/agents/pi-embedded-helpers/errors.ts (modified, +3/-1)
  • ui/src/ui/views/cron.ts (modified, +9/-4)

PR #50089: fix: generalize api_error detection for fallback model triggering

Description (problem / solution / changelog)

Summary

isJsonApiInternalServerError() previously required both "type":"api_error" and the text "internal server error" to classify an error as retryable/fallback-eligible. This caused fallback models to never trigger for providers that use non-standard error messages.

Problem

MiniMax (and potentially other non-Anthropic providers) returns api_error with different message text:

{"type":"api_error","message":"unknown error, 520 (1000)"}

The old check required "internal server error" in the message, so this was not classified as a retryable error, and the configured fallback model was never used.

Fix

Remove the message text requirement. Any response with "type":"api_error" is by definition a provider-side failure — the specific message text is irrelevant to the fallback decision.

Before:

return value.includes(type:api_error) && value.includes("internal server error");

After:

return value.includes(type:api_error);

Risk

Low. The api_error type is defined as a provider-side transient failure. Triggering fallback on all such errors (rather than just those with a specific English message) is the correct, provider-agnostic behavior.

Note on CI

Fork main is behind upstream (~300+ commits). OAuth token lacks workflow scope needed to sync (.github/workflows/ci.yml blocks sync). CI failures are from stale base, not from this one-line change. Same test suite passes on current upstream main.

Fixes #49440 Supersedes #49486 (closed due to branch recreation during rebase attempt)

Changed files

  • src/agents/pi-embedded-helpers/errors.ts (modified, +59/-2)
RAW_BUFFERClick to expand / collapse

Bug type

Crash (process/app exits or hangs)

Summary

Bug: Fallback model does not trigger for api_error responses with non-standard message text (e.g. MiniMax 520) Type: Bug Severity: High — primary model failures surface directly to users; configured fallback is silently ignored Affected version: (current as of 2026-03-18) Component: Error classification / model failover (reply-Bm8VrLQh.js)

Summary When a provider returns an Anthropic-compatible api_error response with a non-standard message string (e.g. "unknown error, 520 (1000)"), OpenClaw's isJsonApiInternalServerError() function returns false because it requires the message to contain "internal server error". This prevents fallback from triggering.

Root Cause In reply-Bm8VrLQh.js, isJsonApiInternalServerError():

javascriptCopyCopied! function isJsonApiInternalServerError(raw) { const value = raw.toLowerCase(); return value.includes(""type":"api_error"") && value.includes("internal server error"); } MiniMax's 520 error body:

JSON "unknown error" ≠ "internal server error" → fallback never triggers.

Proposed Fix javascriptCopyCopied! function isJsonApiInternalServerError(raw) { const value = raw.toLowerCase(); return value.includes(""type":"api_error""); } Workaround Patch the dist file directly — lost on npm upgrade openclaw.

Steps to reproduce

You must be utilizing MiniMax as a service provider and they have some sort of server error. Not deterministically repeatable. The proposed fix generalizes the error handling such that the fallback model is called with any type of API error.

Expected behavior

Correct behavior if API error from MiniMax.io service to move to fallback model

Actual behavior

API error reported to user interface but main agent was not responding

OpenClaw version

OpenClaw 2026.3.13

Operating system

macos 26.3.1 (arm64) · node 25.6.1

Install method

npm

Model

minimax/MiniMax-M2.5-highspeed

Provider / routing chain

openclaw -> minimax

Config file / key location

No response

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Severity: High — primary model failures surface directly to users; configured fallback is silently ignored

Additional information

No response

extent analysis

Fix Plan

To fix the issue, we need to modify the isJsonApiInternalServerError function to correctly identify API error responses with non-standard message text.

  • Update the isJsonApiInternalServerError function in reply-Bm8VrLQh.js to:
function isJsonApiInternalServerError(raw) {
    const value = raw.toLowerCase();
    return value.includes("\"type\":\"api_error\"");
}

This change will allow the fallback model to trigger for any API error response, regardless of the message text.

Verification

To verify that the fix worked, you can test the following scenarios:

  • Simulate an API error response from the MiniMax service with a non-standard message text (e.g. "unknown error, 520 (1000)").
  • Verify that the fallback model is triggered correctly.
  • Check the logs to ensure that the error is handled correctly and the fallback model is used.

Extra Tips

  • To avoid losing the patch on npm upgrade, consider creating a custom fork of the OpenClaw repository with the updated isJsonApiInternalServerError function.
  • Make sure to test the fix thoroughly to ensure that it does not introduce any new issues or regressions.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Correct behavior if API error from MiniMax.io service to move to fallback model

#api#ssr#installation#tensor shape#autograd error#parallel task#integration issue#index setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING