openclaw - 💡(How to fix) Fix Group chat session stuck in 'failed' state silently drops all subsequent messages

Summary

When a group chat session's AI turn fails (e.g. due to timeout), the session is left in a failed state. All subsequent incoming messages are silently dropped — the plugin correctly routes the message, but no new AI turn is started and no error is surfaced to the user.

Environment

• OpenClaw version: 2026.5.22
• Plugin: openclaw-channel-octo v1.0.0
• Channel: Octo (WuKongIM WebSocket)

Steps to Reproduce

1. Bot is active in a group chat.
2. A long-running or resource-intensive AI turn occurs and eventually fails/times out (status: "failed", runtimeMs > 120000ms).
3. After the failure, send any new @mention message to the bot in the same group.
4. Bot receives the message (readReceipt + typing indicator are sent), routing resolves correctly (agentId and sessionKey look good in logs), but no AI turn is started and no reply is sent.

Observed Behavior

Gateway logs show the full inbound processing chain completing successfully:

[octo] [wukongim_bot] recv message ... channel=<groupId> type=2
[octo] [MENTION] 收到@消息 ...
[octo] got runtime, checking dispatch fn: true
[octo] route resolved: agentId=<agent> sessionKey=agent:<agent>:octo:group:<groupId>
[octo] sending readReceipt+typing ...
[octo] typing sent OK / readReceipt sent OK

But there is no registering before_prompt_build hook or deliver-buffer fallback text sent log — the AI turn is never started.

Inspecting sessions.json reveals the group session is stuck in failed state:

{
  "sessionKey": "agent:<agent>:octo:group:<groupId>",
  "status": "failed",
  "abortedLastRun": false,
  "runtimeMs": 394653
}

Root Cause

The session is stuck in failed state from a previous timed-out turn. When dispatchReplyWithBufferedBlockDispatcher is called for the new message, it silently skips starting a new turn because the session is in a failed state. No log, no error message to the user — completely silent.

Workaround

Manually edit sessions.json to set "status": "idle" for the affected group session key, then restart Gateway.

Expected Behavior

When a new inbound message arrives for a session in failed state, the runtime should automatically reset the session to idle before dispatching the new turn, rather than silently dropping the message.

Alternatively, surface an error message to the user in the group channel (e.g. "⚠️ Previous session failed, restarting...") so the issue is visible and self-healing.

Additional Notes

• Private/DM sessions do not exhibit this issue — they appear to recover automatically on the next message.
• The group session sessionKey format is agent:<agentId>:<channel>:group:<channelId>.
• This is reproducible whenever a group turn times out or fails hard (network error, model error, etc.).
• Manual fix requires editing sessions.json + Gateway restart, which is not practical for production use.