Discord listener blocks on slow AI responses, causing multi-minute delays

[yaseenkadlemakki]

Problem

The Discord message listener (DiscordMessageListener) processes MESSAGE_CREATE events synchronously. When the AI takes a long time to generate a response, the listener is blocked for the entire duration — preventing any new Discord messages from being picked up until the response completes.

Observed behavior

From gateway logs:

discord/monitor: Slow listener detected — durationMs: 98362 (98s)
discord/monitor: Slow listener detected — durationMs: 83676 (84s)
discord/monitor: Slow listener detected — durationMs: 126388 (126s)
discord/monitor: Slow listener detected — durationMs: 277248 (277s)
discord/monitor: Slow listener detected — durationMs: 637373 (637s!)

The health monitor eventually restarts Discord due to it being 'stuck', but by then messages have been missed or severely delayed.

Expected behavior

Incoming Discord messages should be acknowledged immediately and processed asynchronously. The listener should not block while waiting for an AI response.

Suggested fix

Decouple message intake from response generation. The MESSAGE_CREATE handler should queue/dispatch the work and return immediately, with response delivery happening async.

Environment

• OpenClaw version: 2026.3.2
• Channel: Discord
• OS: macOS 15.7.3 (arm64)

[KJT125]

Comment for #39145 - Discord listener synchronous blocking

---

Additional Real-World Case: 10-minute Gemini timeout locks Discord channel

We experienced this exact synchronous blocking issue on 2026-03-14. A single slow LLM request locked an entire Discord channel for the full timeout duration.

Timeline

Time	Event
08:11:46	gemini-3-flash-preview request started for channel session
08:13:45	Typing indicator stopped (2min TTL reached)
08:17-08:18	User @mentions bot multiple times → Zero response
08:18	User switches to DM channel → Bot responds normally ✅
08:21:46	LLM timeout after 600,449ms → Lane released
08:21:53	Queued messages start processing

Total duration: 10 minutes of complete channel unresponsiveness

Key Observations

1. Lane locked by single LLM request

   08:21:46 [ERROR] lane task error: durationMs=600449 error="FailoverError: LLM request timed out."
   08:21:53 [WARN] lane wait exceeded: waitedMs=599861 queueAhead=0
   

2. Failover only tried once then gave up

   08:21:46 [WARN] model_fallback_decision: candidate_failed, attempt=1
   

3. DM channel (different lane) worked normally

   • Same bot, same time
   • Different session → different lane → no blocking

4. No queue backlog (queueAhead=0)

   • queueAhead=0 confirms no pending tasks — the lane itself was the bottleneck
   • This is synchronous blocking, not queue saturation
   • New messages couldn't even enter processing

Why This Happened

The DiscordMessageListener is waiting synchronously for the LLM response:

DiscordMessageListener (MESSAGE_CREATE)
  ↓
  Resolve target session
  ↓
  Enqueue to lane
  ↓
  **WAIT for LLM response** ← Blocks here for 10 minutes
  ↓
  Return (listener complete)

During the wait, all new Discord events for this listener are queued but the listener thread is still occupied, creating the illusion of responsiveness (typing indicator) while actually being stuck.

Proposed Fix Confirms

The decoupling proposal in this issue is exactly what would have prevented our incident:

DiscordMessageListener (MESSAGE_CREATE)
  ↓
  Resolve target session
  ↓
  Enqueue to lane (async)
  ↓
  Return immediately ← Listener freed
  
(Meanwhile, lane processes in background)

With async dispatch:

• Listener would return in <1s
• New messages would continue being dispatched
• Only the specific session lane would be blocked (by design)
• Other channels/DMs would be unaffected (already true in our case)

Additional Data Point: 256 Slow Reaction Listeners

On the same day, we logged 256 slow Reaction listener events (1-4 seconds each):

08:06:04 [WARN] Slow listener: ReactionRemoveListener 3729ms
08:05:58 [WARN] Slow listener: ReactionListener 2174ms

While not the direct cause, this shows synchronous listener processing amplifies any slowness in the event chain.

---

This real-world case provides strong evidence for the decoupling fix proposed in this issue. Our 10-minute channel lockout would have been prevented by async event dispatch.

Full technical details: #45589

[anyech]

Fresh follow-up on current OpenClaw 2026.4.15.

I am seeing repeated Discord long-thread cases where a long-running task completes internally but the final reply never surfaces in Discord through the normal assistant reply path.

What I confirmed on current latest-version use:

• the affected long-running work completed internally and produced a normal final answer
• the user-visible Discord thread stayed stuck on the prior visible message instead of surfacing that final answer
• manually sending the same final summary back into the same Discord thread worked immediately
• this still happened after switching local Discord streaming mode to off
• I did not capture fresh Slow listener detected log lines or Discord API errors on these latest repeats; the miss looked silent from the normal reply path

Fresh evidence from today:

• at least two fresh long-running Discord-thread repeats within a few hours on current 2026.4.15 use
• one long-running benchmark-sample result completed internally but did not appear in Discord until I manually backfilled it with an explicit same-thread send
• a later 4-node pilot-verification result also completed internally but again did not appear in Discord until I manually backfilled it with an explicit same-thread send

So the current strongest claim is:

• I am not claiming I isolated the exact listener/transport mechanism for these latest repeats
• I am claiming that on current latest-version use, long-running Discord work can still complete internally while the normal Discord reply path fails to surface the final answer, and the explicit same-thread send path still works as a workaround

This looks like a distinct but plausibly related delivery-failure pattern:

• in this issue, a long-running Discord turn can look stuck because the listener path is blocked during slow handling
• in the repeats I am reporting here, the work completed internally but the normal outbound reply path still failed to surface the final user-visible answer
• both failure shapes produce the same user-visible "stuck" symptom in Discord

Local mitigation already in place on this deployment:

• Discord streaming mode set to off
• long Discord work biased toward final-only / sparse milestone updates
• explicit same-thread send used as the fallback when the final answer does not surface normally

If useful, I can follow up with a tighter minimal repro packet next, but I wanted to add fresh latest-version live evidence first because the miss pattern is still reproducible in real use.

[steipete]

Closing this as implemented after Codex review.

Current main already decouples Discord MESSAGE_CREATE intake from long-running reply generation. DiscordMessageListener.handle() now fire-and-forgets the handler instead of awaiting it, while actual per-session work is queued in the inbound worker with separate timeout controls and coverage proving immediate return/non-serialization behavior.

What I checked:

• Listener no longer blocks on handler completion: DiscordMessageListener.handle() calls this.onEvent?.() and then dispatches this.handler(data, client) via Promise.resolve().then(...) without awaiting it. The inline comment explicitly says the listener now hands work off without blocking Carbon and leaves ordering/timeouts to the inbound worker queue. (extensions/discord/src/monitor/listeners.ts:219, 8d1f98ef08cd)
• Regression tests cover immediate return and lack of same-channel serialization: Tests assert that handle() resolves immediately without waiting for the async handler, and that two messages for the same channel start concurrently rather than serializing behind the first slow run. (extensions/discord/src/monitor/listeners.test.ts:34, 8d1f98ef08cd)
• Inbound work is explicitly queued behind a separate worker: createDiscordMessageHandler() constructs createDiscordInboundWorker(...) and, after preflight, enqueues work with inboundWorker.enqueue(buildDiscordInboundJob(...)) instead of doing the full reply path inline in the listener. (extensions/discord/src/monitor/message-handler.ts:79, 8d1f98ef08cd)
• Queue behavior tests cover stalled-run isolation: Tests verify the handler returns immediately while queued runs execute, and that an explicit inbound worker timeout aborts a stalled run so it does not block the next queued message indefinitely. (extensions/discord/src/monitor/message-handler.queue.test.ts:185, 8d1f98ef08cd)
• Provider wiring separates listener timeout from queued-run timeout: Startup passes Carbon eventQueue.listenerTimeout separately, and tests assert that eventQueue.listenerTimeout is not reused as the inbound worker timeout while inboundWorker.runTimeoutMs is forwarded independently. (extensions/discord/src/monitor/provider.ts:1081, 8d1f98ef08cd)
• Docs now describe the split control plane: Discord docs distinguish the listener budget (channels.discord...eventQueue.listenerTimeout) from the queued worker budget (channels.discord...inboundWorker.runTimeoutMs) and recommend using the latter only as a separate safety valve for queued turns. Public docs: docs/channels/discord.md. (docs/channels/discord.md:1054, 8d1f98ef08cd)

So I’m closing this as already implemented rather than keeping a duplicate issue open.

Review notes: reviewed against 84fc00afdacb; fix evidence: commit 8d1f98ef08cd.