Bug Report: Idle Slack Thread Session Reset Loses Triggering Message

Summary

When a Slack thread session is idle for ~30 minutes and receives a new message, OpenClaw resets the session but loses the incoming message that triggered the reset. The message is never delivered to either the old or new session.

Environment

• OpenClaw version: 2026.5.4 (325df3e)
• Channel: Slack (socket mode)
• Session type: Thread session (topic_id-based)

Steps to Reproduce

1. Have an active Slack thread conversation with the agent
2. Agent responds, then thread goes idle for 25-30+ minutes
3. User sends a new message mentioning the agent in that thread
4. Expected: Agent receives and responds to the message
5. Actual: Agent starts typing (session creating), then stops. Message is lost. User must ping again.

Evidence from Session Files

Timeline (2026-05-05 UTC)

• 03:33:22 - User message in thread (delivered, agent responded)
• 03:34:01 - Agent completed response (session idle after this)
• 04:03:30 - User pings: "@ghosty what do you think" ← THIS MESSAGE LOST
• 04:03:32 - Session reset triggered (.reset file created)
• 04:03:35 - New session created (ID changed from 3e057aaa... to 55a9502a...)
• 04:06:08 - User pings again: "@ghosty are you receiving my msgs"
• 04:06:12 - New session receives this message and responds

Session Files

Old session (reset):

/root/.openclaw/agents/main/sessions/3e057aaa-e4ab-4854-b2d9-9ddb9d05a370-topic-1777951172.213659.jsonl.reset.2026-05-05T04-03-32.349Z

New session (created after reset):

/root/.openclaw/agents/main/sessions/55a9502a-3efd-435b-9d35-a9ca9a3dc629-topic-1777951172.213659.jsonl

Key Observation

The old session transcript shows a clean completion at 03:34:01 with "stopReason":"stop". The session was NOT stuck - it was simply idle. The safety mechanism incorrectly treated 29 minutes of idleness as "stuck" and reset it.

The message at 04:03:30 (visible in Slack API: ts=1777953810.470989) never appears in either session's transcript.

Root Cause Hypothesis

The session routing logic for thread messages triggers a reset for idle sessions when a new message arrives, but fails to preserve/deliver the incoming message to the new session.

Expected Behavior

When resetting an idle thread session on new message arrival, OpenClaw should either:

1. Not reset if there's an incoming message (proves session is not stuck, just idle)
2. OR Preserve the triggering message and deliver it to the new session
3. OR Load recent thread history into the new session to maintain context

Workaround

User must ping twice after long idle periods. First ping triggers reset (lost), second ping is received.

Impact

• Moderate: Annoying but not blocking
• Frequency: Any thread idle >25-30 minutes
• Affected: Thread sessions only (DMs and main channel sessions don't exhibit this)