Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When an LLM request times out during agent execution, the agent correctly logs decision=surface_error reason=timeout but the Web UI hangs indefinitely showing a loading spinner instead of displaying a timeout error.

Steps to reproduce

1. Deploy OpenClaw with Docker (or any deployment method)
2. Configure a slow LLM provider (e.g., minimax-m2.5 via NVIDIA API) that occasionally takes >60 seconds to respond
3. Send a message through the Web UI
4. Observe that when the LLM response exceeds the agent timeout threshold, the connection is aborted (ConnectionAbortedError in gateway logs)
5. Observe that the Web UI continues to show a loading spinner indefinitely, never displaying an error message or recovering

Expected behavior

When an agent run times out, the agent should return a status: "timeout" via agent.wait and the Web UI should receive a final event with error information, then display an appropriate timeout error message to the user and allow retry.

Actual behavior

• Gateway logs show ConnectionAbortedError: [WinError 10053] indicating the client (OpenClaw) aborted the connection
• Agent logs show decision=surface_error reason=timeout
• The Web UI spinner continues indefinitely
• No error message is displayed
• The user cannot retry without refreshing the page

OpenClaw version

2026.4.9

Operating system

Linux (Docker deployment: Ubuntu-based container, host OS Windows 11)

Install method

docker

Model

minimax-m2.5 (via NVIDIA API)

Provider / routing chain

openclaw -> ai_router.py (custom gateway) -> NVIDIA API -> minimax-m2.5

Additional provider/model setup details

Custom gateway implementation (ai_router.py) handles streaming requests to NVIDIA API with retry logic. The gateway correctly streams responses and handles timeouts, but the agent's timeout mechanism cuts the connection before the gateway can return a proper error response to the UI.

Logs, screenshots, and evidence

Gateway logs showing the timeout and connection abort:
[LLM-Gateway][INFO] 流式尝试 1/4
[LLM-Gateway][INFO] 流式响应状态码: 200
[LLM-Gateway][ERROR] ⚠️ 流式请求异常 RemoteProtocolError (尝试 1/4) - Server disconnected without sending a response.
[LLM-Gateway][INFO] 等待 1s 重试...
...
[LLM-Gateway][INFO] 流式尝试 2/4
[LLM-Gateway][INFO] 流式响应状态码: 200
...
ConnectionAbortedError: [WinError 10053] 你的主机中的软件中止了一个已建立的连接。

========================================================================

Agent logs showing timeout detection:
[agent] embedded run failover decision: runId=... stage=assistant decision=surface_error reason=timeout provider=sweetmido/minimax-m2.5

Impact and severity

• Affected users/systems/channels: All Web UI users when using slow LLM providers
• Severity: High (blocks workflow, makes UI unusable until page refresh)
• Frequency: Intermittent (occurs when LLM response exceeds agent timeout threshold)
• Consequence: Users see indefinite loading spinner, cannot retry, must refresh page losing conversation context

Additional information

• The issue appears to be that when the agent aborts a run due to timeout, the final event with error status never reaches the Web UI, possibly because the WebSocket connection is terminated before the event can be sent.
• Workaround: Refresh the page, though this loses conversation context.
• The custom gateway (ai_router.py) functions correctly and retries on network errors, but cannot compensate for the agent aborting the connection.
• Suggest: Ensure final event with status: "timeout" is always sent to the Web UI before or during connection teardown when a timeout occurs.