Timeout (AbortError) does not trigger fallback model chain

[Dazee-daze]

Summary

When an LLM request hits the hard timeout (AbortError), the extension throws an error outside the fallback for loop, causing the full fallback model chain to be silently skipped. No fallback model is ever tried on timeout — only on provider errors (4xx/5xx).

Expected Behavior

On AbortError (request timeout), the loop should continue to the next model in the fallback chain — the same behavior that occurs when a provider returns a 4xx/5xx error.

Actual Behavior

The throw in the AbortError handler (around proxy.ts line 1102) exits the try/catch and the entire for loop. The full fallback chain configured in openclaw.json is never invoked on timeouts.

Steps to Reproduce

1. Configure a multi-model fallback chain in openclaw.json
2. Send a high-complexity request (long context + image attachments) that exceeds the DEFAULT_REQUEST_TIMEOUT_MS threshold
3. Observe: the primary model times out, no fallback model is attempted, the request fails with a hard FailoverError

Root Cause

In proxy.ts, the AbortError catch block throws unconditionally:

if (err instanceof Error && err.name === "AbortError") throw new Error(`Request timed out...`)

This throw exits the fallback for loop entirely instead of continue-ing to the next model.

Suggested Fix

Move the timeout handler inside the fallback loop so it can continue to the next model:

// Inside the fallback for loop
if (err instanceof Error && err.name === "AbortError") {
  console.warn(`Model ${modelId} timed out, trying next fallback...`);
  continue; // instead of throw
}

Environment

• OpenClaw gateway with ClawRouter extension
• Fallback chain: claude-max/claude-sonnet-4 → claude-max/claude-opus-4 → openai-codex/gpt-5.3-codex → (additional fallbacks)
• Hard timeout: DEFAULT_REQUEST_TIMEOUT_MS (~180–300s)
• Observed: 7+ timeout failures in a single session, all skipping the fallback chain

Impact

Users relying on fallback chains for reliability get hard failures on timeout instead of automatic model fallover. This defeats the purpose of the fallback configuration.

[1bcMax]

Thanks for the detailed report! After investigating, the behavior is slightly different from what's described but the end result is the same — timeout kills the entire fallback chain.

What actually happens in ClawRouter's code:

1. tryModelRequest() already catches AbortError internally (line 2135) and returns { success: false, isProviderError: true } — so the error does NOT throw out of the fallback loop
2. The fallback loop sees isProviderError: true and continues to the next model
3. But — all models share a single AbortController (line 3253). Once the global timeout fires controller.abort(), the signal is permanently dead. Every subsequent fallback model's payFetch immediately throws AbortError too — they all fail instantly without ever reaching the provider

So the fallback models are technically "tried" but they all fail in <1ms because the abort signal is already triggered. Net effect is the same as what you described — no real fallback on timeout.

Fix approach: Create a fresh AbortController per fallback attempt, each with its own timeout budget (e.g. remaining time divided among remaining models, or a fixed per-model timeout). This way model 2 gets a real chance if model 1 times out.

One note: The model names in your report (claude-max/claude-sonnet-4, openai-codex/gpt-5.3-codex) and proxy.ts line 1102 look like they're from the OpenClaw gateway layer, not ClawRouter. If you're seeing this in the OpenClaw gateway proxy specifically, it may be a separate issue there. Could you confirm which layer you're hitting the timeout in?

Will work on a fix for the shared AbortController issue on the ClawRouter side.