openclaw - 💡(How to fix) Fix Session lane stuck in 'running' after run dies — sessions.abort + gateway restart fail to clear stale state [1 participants]

Bug Description

Session lanes get permanently stuck in status: "running" after the actual LLM run dies. The stale running state is not cleared by:

1. sessions.abort RPC (returns {"status": "no-active-run"} confirming the run is dead)
2. Gateway restart (stale state persists through restart)

This blocks the session lane indefinitely — every new message queues behind the dead lock and is never processed.

Scope

This is broader than #16331 (compaction-triggered lane jams). Any run that dies without proper lifecycle cleanup can cause this — we observed it across webchat, cron, home-node, and default sessions simultaneously.

Evidence (2026-04-02, version 2026.3.24)

11 zombie sessions found in a single check, some stuck for over a week:

agent:main:home-tablet-kitchen:  running for 10,571 min (7.3 days)
agent:main:home-tablet-test2:    running for 9,983 min
agent:main:home-tablet-test3:    running for 9,980 min
agent:main:default:              running for 2,888 min (2 days)
agent:main:web_..._7ad797481643: running for 1,309 min
agent:main:cron:721fa3b5-...:    running for 949 min
agent:home:default:              running for 203 min
agent:home:debug:                running for 189 min

Every single one returned "no-active-run" on sessions.abort.

Gateway logs show lane wait warnings going back hours:

lane wait exceeded: lane=session:agent:main:main waitedMs=1309962 queueAhead=2
lane wait exceeded: lane=session:agent:main:main waitedMs=842773 queueAhead=1
lane wait exceeded: lane=session:agent:main:main waitedMs=539336 queueAhead=0

Impact

• Multiple users unable to get responses on webchat (messages silently queue forever)
• No error surfaced to the user — just permanent silence
• Affects any session type (webchat, cron, home-node, default)

Workaround

Sending /new via sessions.send RPC clears the stale state:

openclaw gateway call sessions.send \
  --params '{"key":"agent:main:main","message":"/new"}' \
  --timeout 15000

We have deployed a watchdog script that runs every 10 minutes, detects sessions stuck in "running" beyond 20 minutes with no active run, and auto-recovers via /new.

Expected Behavior

1. sessions.abort should clear stale running state when no active run exists
2. Gateway restart should reconcile session status against actual run state
3. Ideally: a session-lane timeout that auto-recovers after a configurable threshold

Environment

• OpenClaw 2026.3.24 (cff6dc9)
• macOS ARM64 (Mac Studio)
• Node v25.8.1
• Model: anthropic/claude-opus-4-6 (1M context)