Summary
An agent run wedged mid-turn: the last model call ended, but the run never advanced to the next tool call or to completion. The diagnostic subsystem correctly detects and logs the stall (classification=stalled_agent_run) but reports recovery=none and takes no action. The session stays state=processing indefinitely, with a queued message stuck behind it, until an operator intervenes.
Observed (production log)
[diagnostic] stalled session: sessionId=<id> sessionKey=agent:main:user:<uid>:chat:<key>
state=processing age=216s queueDepth=1 reason=active_work_without_progress
classification=stalled_agent_run activeWorkKind=embedded_run
lastProgress=model_call:ended lastProgressAge=142s recovery=none
[diagnostic] stalled session: sessionId=<id> ...
state=processing age=246s queueDepth=1 reason=active_work_without_progress
classification=stalled_agent_run activeWorkKind=embedded_run
lastProgress=model_call:ended lastProgressAge=172s recovery=none
age climbs each tick (216s → 246s → …); the run never self-clears.
lastProgress is stuck at model_call:ended — the model returned, but nothing advanced afterward.
recovery=none on every tick.
queueDepth=1 — a follow-up message is blocked behind the wedged run.
Impact
On Clawnify.com (managed OpenClaw platform) this stranded an in-progress task partway through. The only ways to clear it were an operator Stop or a gateway restart; the run would otherwise sit in processing indefinitely.
Questions / ask
- For
classification=stalled_agent_run, should the detector attempt auto-recovery (re-drive / abort + requeue the pending message) rather than only observe? Today recovery=none means the detector names the problem but leaves the session wedged.
- If
recovery=none is intentional for this class, what is the documented operator remediation?
- Root cause: what leaves a run at
lastProgress=model_call:ended with no subsequent step — e.g. an empty/failed model response, or a tool-dispatch path that doesn't advance the state machine after the model returns?
Environment
- OpenClaw
2026.6.5 (5181e4f), self-hosted gateway, activeWorkKind=embedded_run.
- Possibly related to heartbeat / pending-run starvation reports.
Summary
An agent run wedged mid-turn: the last model call ended, but the run never advanced to the next tool call or to completion. The diagnostic subsystem correctly detects and logs the stall (
classification=stalled_agent_run) but reportsrecovery=noneand takes no action. The session staysstate=processingindefinitely, with a queued message stuck behind it, until an operator intervenes.Observed (production log)
ageclimbs each tick (216s → 246s → …); the run never self-clears.lastProgressis stuck atmodel_call:ended— the model returned, but nothing advanced afterward.recovery=noneon every tick.queueDepth=1— a follow-up message is blocked behind the wedged run.Impact
On Clawnify.com (managed OpenClaw platform) this stranded an in-progress task partway through. The only ways to clear it were an operator Stop or a gateway restart; the run would otherwise sit in
processingindefinitely.Questions / ask
classification=stalled_agent_run, should the detector attempt auto-recovery (re-drive / abort + requeue the pending message) rather than only observe? Todayrecovery=nonemeans the detector names the problem but leaves the session wedged.recovery=noneis intentional for this class, what is the documented operator remediation?lastProgress=model_call:endedwith no subsequent step — e.g. an empty/failed model response, or a tool-dispatch path that doesn't advance the state machine after the model returns?Environment
2026.6.5(5181e4f), self-hosted gateway,activeWorkKind=embedded_run.