openclaw - 💡(How to fix) Fix [Bug]: Model fallback not triggered on HTTP 500 errors, leading to system unresponsiveness [1 comments, 2 participants]

Bug type

Crash (process/app exits or hangs)

Beta release blocker

No

Summary

I encountered an issue where the system became completely unresponsive when the primary model returned an HTTP 500 Internal Server Error, despite having a configured model ladder (fallbacks). The expected behavior was for the gateway to trigger a failover to the secondary models (e.g., Ollama), but instead, the request simply failed without any response.

Steps to reproduce

1. Configure a model ladder with a primary provider (e.g., Google Gemini) and fallback providers (e.g., Ollama).
2. Trigger a scenario where the primary provider returns an HTTP 500 Internal Server Error.
3. Observe that the system does not switch to the fallback model and remains unresponsive.

Expected behavior

Any HTTP 5xx error (specifically 500, 502, 504) should reliably trigger the classifyFailoverReason logic and initiate a switch to the next model in the fallback ladder to ensure high availability.

Actual behavior

The system became completely unresponsive when the primary model returned an HTTP 500 Internal Server Error, despite having a configured model ladder (fallbacks).

OpenClaw version

v2026.5.7

Operating system

Ubuntu 24.04

Install method

npm install -g openclaw@latest

Model

google/gemma-4-31b-it

Provider / routing chain

openclaw -> google

Additional provider/model setup details

Primary Model: google/gemma-4-31b-it Fallbacks: ollama/gemma4:31b-cloud

Logs, screenshots, and evidence

Impact and severity

The system became completely unresponsive when the primary model returned an HTTP 500 Internal Server Error.

Additional information

Upon inspecting the compiled distribution code, it appears that the logic to handle 500 errors is already present but may not be executing as expected in certain scenarios (e.g., when the error is wrapped in a JSON body or returned as a non-standard HTML page).

In dist/errors-BqFqz2qx.js (which corresponds to src/errors.ts), the following logic exists:

if (status === 500 || status === 502 || status === 504) return toReasonClassification("timeout");

This indicates that HTTP 500, 502, and 504 errors are intended to be classified as timeout, which should normally trigger the failover mechanism. However, in practice, this classification is either not being reached or the subsequent failover process is failing silently.