openclaw - 💡(How to fix) Fix Bug: session stuck in status:"running" after surface_error from failover chain [1 comments, 2 participants]

Summary

When the failover chain surfaces surface_error reason=timeout (commonly downstream of #73789, but in principle any cause), the session-state machine does not transition out of status: "running". Subsequent user messages on the session don't process — the gateway treats them as queued behind a run that will never complete. The session is wedged until manually patched in sessions.json and the gateway restarted.

This is downstream of #73789 / 1dbc250b1a / #73930. Those address the cause (empty input). This is about the lifecycle gap that lets the wedge persist independent of which upstream cause produced the surface_error.

Environment

• OpenClaw: 2026.4.26
• Provider/model: primary openai-codex/gpt-5.4, fallbacks anthropic/claude-sonnet-4-6, openai-codex/gpt-5.4-mini
• Surface: Telegram direct session (also reproduces for cron-driven sessions and agent CLI)
• Runtime: gateway via Node 25.9.0 on macOS 26.4.1

Repro

1. From a Telegram session bound to openai-codex/gpt-5.4, send a message that triggers the empty-input bug from #73789 (or any other cause that walks the failover chain to surface_error).
2. Observe the failover chain run and surface surface_error reason=timeout.
3. Send another message on the same session.

Expected

After surface_error, the session transitions to a terminal state (e.g. done with an error marker), an error is delivered to the channel, and the next message is accepted normally.

Actual

The session remains in status: "running" in sessions.json. New messages don't process. From the user side this looks like the bot typing then never responding. Gateway restarts don't recover it — the status field is persisted to disk and rehydrated on startup.

Concrete state in ~/.openclaw/agents/main/sessions/sessions.json after the wedge:

status: "running"
abortedLastRun: false
updatedAt: <hours ago, frozen at the failover timestamp>

Logs

2026-04-29T13:02:07.998-05:00 [agent/embedded] embedded run failover decision: runId=f8ec3197-... stage=assistant decision=surface_error reason=timeout from=openai-codex/gpt-5.4-mini profile=sha256:c21d1bebb3b0

After this entry: no further agent/embedded activity for the session, no transition to a done state, no error message delivered to the channel. Diagnostic stuck-session warnings keep firing every 30s but nothing recovers:

2026-04-29T14:03:32.509-05:00 [diagnostic] stuck session: sessionId=main sessionKey=agent:main:telegram:direct:... state=processing age=143s queueDepth=0
2026-04-29T14:04:02.513-05:00 [diagnostic] stuck session: ... age=173s
2026-04-29T14:04:32.512-05:00 [diagnostic] stuck session: ... age=203s

Suspected cause

The session-state machine has transitions for normal completion and explicit abort, but appears to lack a transition out of running for the surface_error outcome of the failover chain. Once the chain surfaces an error, no code path moves the session to a terminal state. The [diagnostic] stuck session warnings detect the condition but don't drive recovery.

Workaround

Back up sessions.json, set status: "running" → "done" and abortedLastRun: false → true on the affected session key, restart the gateway. Session resumes accepting messages immediately.

Relation to existing issues

• #73789 — provides the most common upstream cause (empty input from bare /new)
• #73930 — fail-fast guard would convert the 15–31s timeout into an immediate error, which might give the session machine a cleaner exit signal, but doesn't directly fix the missing transition described here
• 1dbc250b1a — same as above

This issue is meant to track the lifecycle gap independent of which upstream cause produced the surface_error.