Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When configured with fallback and multiple API key rotation, TUI stops displaying output after receiving an error event, even when the background model fallback is still executing and eventually succeeds. User has to manually refresh the page to see the result.

Steps to reproduce

1. Configure multiple API keys (with rotation enabled)
2. Configure fallback models
3. Send a message that triggers rate limit (API returns 429)
4. Observe TUI displays run error: API rate limit reached
5. Wait for fallback to complete successfully
6. Result: TUI does not display the fallback output; manual page refresh required

Expected behavior

TUI should continue displaying the fallback output, or at least show a message like "Trying fallback model..." while waiting.

Actual behavior

TUI shows error and immediately stops output. Gateway logs show fallback actually succeeded in the background, but TUI does not display the result. User can only see the latest execution result by clicking refresh on the web page.

OpenClaw version

2026.4.2

Operating system

WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2) on Windows 11

Install method

npm global

Model

minimax (primary), qwen3-235b and glm-4.7 (fallbacks)

Provider / routing chain

openclaw -> custom provider -> minimax2.5 (error) -> custom provider -> quwen3-235b

Additional provider/model setup details

• Configured multiple API keys for rotation
• Configured fallback models: qwen3-235b, glm-4.7
• Using webchat channel
• Primary model: custom-provider/minimax-m25

Logs, screenshots, and evidence

Impact and severity

• Affected: Users using TUI/webchat with fallback or multiple API keys configured
• Severity: Medium (impacts user experience, requires manual refresh)
• Frequency: Occurs every time rate limit is encountered
• Consequence: User cannot see fallback success result, needs additional operation

Additional information

This is a behavior bug, not a crash. Root cause analysis:

1. When TUI receives error event, it calls terminateRun() -> streamAssembler.drop(runId)
2. This discards all state for that run
3. Even though model fallback continues executing in background, TUI no longer displays output
4. User must manually refresh to see results

Suggested fix: Modify TUI to not immediately terminate the run on error. Instead, mark it as "waiting for fallback" and continue displaying output when fallback succeeds.

Code location: src/tui/tui-event-handlers.ts line ~315

// Current behavior - terminates immediately
if (evt.state === "error") {
  terminateRun({ status: "error" });  // ← drops state
}

// Suggested fix - wait for fallback
if (evt.state === "error") {
  // Don't terminate
  // Show friendly message
  chatLog.addSystem("API overloaded, trying fallback model...");
  // ← continue waiting for fallback result
}