Bug Description

When OpenClaw session compaction triggers on a long-running session, the InteractionEventListener on the critical lane times out with a 120-second listener-timeout error. Incoming Discord messages are silently dropped without any user-facing error or retry.

This is a regression from the expectation that the gateway should NACK/retry messages that cannot be appended to a locked session, rather than letting them queue until the listener timeout silently kills the lane.

Reproduction

1. Start a session that accumulates enough context to trigger compaction (e.g., multiple model fallback attempts)
2. Wait for compaction to begin (agent/embedded subsystem: compaction retry aggregate timeout)
3. Send a Discord message during the compaction window
4. Message is received by Discord gateway, queued, but never appended to the session
5. InteractionEventListener hits 120s timeout; message is dropped with no user notification

Exact log evidence (2026-04-28 02:26–02:28 UTC)

2026-04-28T02:26:37.733Z warn agent/embedded incomplete turn detected: 
  runId=96c9f2aa-26a0-47b3-a105-b36170dc862c 
  sessionId=517c9845-d14c-4750-8699-5af0fe93493b 
  stopReason=stop payloads=0

2026-04-28T02:26:37.736Z warn model-fallback/decision candidate_failed:
  requested=minimax-portal/MiniMax-M2.7 
  reason=format code=incomplete_result 
  errorPreview="minimax-portal/MiniMax-M2.7 ended with an incomplete terminal response"

2026-04-28T02:27:53.762Z warn agent/embedded 
  compaction retry aggregate timeout (60000ms): 
  proceeding with pre-compaction state 
  runId=96c9f2aa-26a0-47b3-a105-b36170dc862c 
  sessionId=517c9845-d14c-4750-8699-5af0fe93493b

2026-04-28T02:27:53.763Z warn agent/embedded 
  using pre-compaction snapshot: timed out during compaction

2026-04-28T02:27:57.990Z ERROR event-queue 
  type=listener-timeout 
  listener=InteractionEventListener 
  eventType=INTERACTION_CREATE 
  lane=critical 
  timeoutMs=120000

Impact: User sent a message at 02:27 UTC. It was never processed — the session started fresh at 02:28 UTC with seq=1, meaning the message was entirely lost.

Expected Behavior

When the session file is locked for compaction, the gateway should:

1. Fail fast with a "session busy" response to Discord (causing Discord to retry via exponential backoff), OR
2. Buffer messages to a persistent queue that survives the compaction and is drained afterward, OR
3. Use non-blocking compaction (copy-on-write or temp-file swap) so the session lock is never held for more than milliseconds

Actual Behavior

Messages queue in memory, the listener timeout fires at 120s, and the message is silently dropped. The user receives no feedback and must manually resend.

Environment

• OpenClaw: 2026.4.25 (aa36ee6)
• OS: Ubuntu 24.04 (Linux 6.8.0-110-generic x64)
• Node: v24.14.1
• Model: minimax-portal/MiniMax-M2.7 (primary) → MiniMax-M2.1 (fallback) → openrouter/minimax/minimax-m2.5:free (tertiary)
• Channel: Discord
• Session: native OpenClaw session compaction (not LCM)

Related Issues

• #68401 — "Feature: Allow message processing during session compaction" (feature request for background compaction)
• #66646 — "Session file lock errors cascade through model fallback chain" (lock errors treated as model failures)
• #64362 — "Main agent response lost after tool execution" (dead-pid lock cleanup causes lost responses)
• #57248 — "InteractionEventListener stalls up to 78s on Discord" (closed — same symptom, different root cause: session-memory hook blocking)
• #59218 — "Session-memory hook blocks Discord InteractionEventListener" (closed — same symptom, root cause was synchronous disk writes from cron hook)

Severity

HIGH — Messages are silently lost with no user feedback. The user has no way to know their message was dropped unless they happen to resend and compare timestamps.

Suggested Fix

The most strategic fix is non-blocking compaction: instead of holding a WRITE lock on the session JSONL file while compacting, the compaction process should:

1. Write the compacted state to a .tmp file
2. Perform an atomic rename() to swap the old file with the compacted one
3. Never hold the session lock for more than a few milliseconds

This eliminates the root cause entirely without requiring complex queue infrastructure.

Hypothesis (to be verified)

The session lock is held during the entire compaction I/O + LLM summarization cycle (60+ seconds). The InteractionEventListener waits for the session to accept the new message but the session file is locked. The 120s listener timeout then fires and kills the event without retrying.