openclaw - 💡(How to fix) Fix Discord WebSocket silently drops — messages not delivered to gateway [1 comments, 2 participants]

Summary

The Discord WebSocket connection silently disconnects, causing the gateway to stop receiving inbound messages (including @mentions). No error is logged, no reconnect is triggered — the connection just goes dead.

Environment

• OpenClaw version: 2026.4.15 (041266a)
• OS: macOS (Apple Silicon), residential internet
• Discord.js via @openclaw/discord plugin
• Config: requireMention: true, groupPolicy: allowlist

Observed Behavior

This has occurred on two consecutive days (April 30 and May 1, 2026):

1. Discord integration works normally — messages arrive, discord-auto-reply logs preflight checks
2. At some point, the WebSocket silently dies
3. New messages from Discord (including direct @bot mentions) produce zero log entries — they never reach the preflightDiscordMessage handler
4. The gateway process remains running and responsive on other channels (webchat works fine)
5. The message tool can still send to Discord (REST API works), but receiving is dead
6. Only fix is a full gateway restart, which re-establishes the WebSocket

Evidence from Logs (May 1, 2026)

09:11 — discord-auto-reply preflight fires (skip: no-mention) ✅ working
09:13 — discord-auto-reply preflight fires (skip: no-mention) ✅ working
09:26 — user @mentions bot in #general — ZERO log entries ❌ dead
09:27 — user @mentions bot again — ZERO log entries ❌ dead
09:28 — user @mentions bot again — ZERO log entries ❌ dead
09:29 — manual gateway restart fixes it

No WebSocket error, close, or reconnect events appear in logs between 09:13 and 09:29.

Expected Behavior

• Discord.js should detect the dropped connection via its internal heartbeat
• Auto-reconnect should fire and re-establish the WebSocket
• If reconnect fails, an error should be logged

Suspected Cause

Silent WebSocket disconnect, likely due to:

• NAT timeout on residential connection dropping the TCP session
• Discord gateway heartbeat ACK not being checked aggressively enough
• discord.js shardDisconnect / shardError events may not be firing

Current Workaround

A cron-based watchdog (every 15 min) that checks Discord responsiveness and auto-restarts the gateway if unresponsive.

Suggested Fix

1. Hook into discord.js shardDisconnect, shardError, shardReconnecting events and log them
2. Consider a more aggressive heartbeat check or periodic ping to detect dead connections faster
3. If the shard goes unresponsive for >2 minutes, force a reconnect rather than waiting for the library's internal detection

Impact

High — this makes the bot appear offline/unresponsive to users on Discord, which is the primary interaction channel. Has occurred on 2 of 2 consecutive days observed.