ClawKit Logo
ClawKitReliability Toolkit

Fix DiscordMessageListener Blocking and Agent Timeouts in OpenClaw

TL;DR โ€” Quick Fix

The DiscordMessageListener synchronously blocks during long agent tasks, causing message queue stalls; the fix involves non-blocking event dispatching.

Run Diagnostics

Next Step

Fix now, then reduce repeat incidents

If this issue keeps coming back, validate your setup in Doctor first, then harden your config.

Error Signal

[discord] Slow listener detected: DiscordMessageListener took Xs seconds for event MESSAGE_CREATE[agent/embedded] embedded run timeout: runId=xxx timeoutMs=600000

What's Happening

Your Discord messages are getting stuck in a queue. The DiscordMessageListener is taking too long to process incoming MESSAGE_CREATE events, sometimes over several minutes. This causes subsequent messages to never be processed, and you'll see your agent's typing indicator start but never finish. The only way to get things moving again is to restart the OpenClaw gateway.

The Fix

The core issue has been resolved by merging commit f51cac2775d393fa1e0f18308bf7e912f6dc47e4 into the main branch. This change makes the DiscordMessageListener dispatch events in a non-blocking, fire-and-forget manner. This means long-running agent tasks won't stall the message processing queue for unrelated incoming messages.

Ensure you are running a version of OpenClaw that includes this fix. If you're on an older version, you'll need to update.

Why This Occurs

Previously, the DiscordMessageListener handled message processing synchronously. If an agent task (like a complex tool call or multi-step AI work) took a long time, the listener was blocked for that entire duration. Any new Discord messages arriving during this block would be delayed, leading to the queue backup and eventual stalls. This created a bottleneck where one long-running task could freeze all incoming message processing.

The log messages [discord] Slow listener detected: DiscordMessageListener took Xs seconds for event MESSAGE_CREATE and [agent/embedded] embedded run timeout: runId=xxx timeoutMs=600000 are direct symptoms of this synchronous blocking behavior.

Prevention

Keep your OpenClaw instance updated to the latest main branch or a stable release that incorporates the fix from f51cac2775d393fa1e0f18308bf7e912f6dc47e4. Regularly monitor your OpenClaw logs for Slow listener detected warnings. While the fix addresses the root cause of the queue stall, exceptionally long agent tasks might still take time to complete, but they should no longer block the processing of new messages indefinitely.


Last Updated: March 2026

Did this guide solve your problem?