openclaw - 💡(How to fix) Fix [Bug]: Telegram /stop and /status queue behind stuck topic lane instead of preempting

Summary

When a Telegram forum topic/session is stuck in a long-running or wedged agent turn, control commands like /stop and /status appear to be enqueued behind the same per-topic FIFO lane. That means the commands cannot stop or inspect the stuck run they are meant to recover.

Environment

• OpenClaw: 2026.5.12
• Image revision: f066dd2f31c231f38fbcaacd6f6dfce0801143b3
• Install type: Docker
• Channel: Telegram supergroup forum topic
• Runtime involved during the observed incident: Codex app-server / embedded agent

Observed behavior

On 2026-05-17, a Telegram topic stalled during a Codex-runtime turn. The logs showed repeated idle timeouts and timeout-compaction before fallback:

[agent/embedded] codex app-server turn idle timed out waiting for completion
[agent/embedded] [timeout-compaction] LLM timed out with high prompt token usage (90%); attempting compaction before retry
[agent/embedded] embedded run failover decision ... reason=timeout from=openai/gpt-5.5 ... rawError=codex app-server attempt timed out

While that topic was stuck, the local Telegram ingress spool contained a later /status@botname update for the same topic. The status command did not return because it remained queued behind the stuck topic lane. In a similar incident the day before, /stop@botname was also queued behind an earlier normal message in the same Telegram topic and never executed until the local spool was manually drained.

A gateway restart alone can replay the same queued Telegram updates and re-wedge the topic unless the operator manually moves files out of ~/.openclaw/telegram/ingress-spool-*.

Expected behavior

Telegram control commands such as /stop and /status should be recognized before normal agent-turn dispatch and should be able to bypass or preempt the blocked per-topic queue. At minimum:

• /status should return diagnostic state even when the topic's active agent turn is stuck.
• /stop should be able to cancel the active stuck turn instead of waiting behind it.
• Control commands should not require external gateway restarts or manual spool surgery.

Actual behavior

Control commands are treated like ordinary Telegram updates in the same per-topic queue/spool. If an earlier turn is wedged, recovery commands wait behind it indefinitely.

Impact

• Users cannot recover a stuck Telegram topic from Telegram itself.
• /stop and /status fail precisely when they are most needed.
• Operators may need to stop the gateway and manually drain ~/.openclaw/telegram/ingress-spool-*.
• Gateway restarts may replay the same stuck queue and reproduce the failure.

Related issues

This is related to, but distinct from:

• #71127, where stuck processing sessions are detected but not aborted.
• #83109, where Codex-runtime tool turns can stall.

Even if those root causes are fixed, Telegram control commands should probably still bypass the blocked FIFO topic lane so users can inspect or recover stuck sessions from chat.