Bug type

Regression

Beta release blocker

Yes

Summary

Discord channel never reaches "ready" state after a stale-socket recovery cycle, leaving the bot unable to send/receive messages. The gateway WebSocket connects and exchanges heartbeats, but Carbon's ready event never fires.

Steps to reproduce

1. Run OpenClaw gateway with Discord channel enabled (using @buape/carbon)
2. Wait for health-monitor to detect a stale Discord WebSocket ([health-monitor] restarting (reason: stale-socket))
3. After the restart, Discord logs "client initialized as ...; awaiting gateway readiness" and never progresses
4. All subsequent service restarts reproduce the same stuck state

Alternatively: any gateway restart after the initial stale-socket event reproduces this — the Discord channel never recovers.

Expected behavior

After a stale-socket detection and Discord provider restart, the Carbon client should:

1. Connect to Discord gateway WebSocket
2. Complete IDENTIFY handshake
3. Receive READY + GUILD_CREATE events
4. Emit the ready event so messages can be sent/received

This worked correctly on versions prior to ~2026.3.24.

Actual behavior

• TCP connection to gateway.discord.gg succeeds (ESTAB, ~44KB received from Discord)
• Discord heartbeats are exchanged (bytes_sent/bytes_received increase over time)
• But the Carbon ready event never fires
• Log stays permanently at: [discord] client initialized as ...; awaiting gateway readiness
• Heartbeat module reports Unknown Channel because channel cache is never populated
• All message delivery fails with Unknown Channel

OpenClaw version

Tested on 2026.3.24, 2026.3.28, and 2026.3.31-beta.1 — all exhibit the same behavior.

Operating system

Arch Linux x86_64, kernel 6.19.10-1-cachyos, 4GB RAM VPS (Shin)

Install method

npm install -g openclaw (system-wide, /usr/lib/node_modules/openclaw)

Model

volcengine/kimi-k2.5 (primary), but model is irrelevant — this is a channel/transport issue.

Provider / routing chain

NOT_ENOUGH_INFO (not model-related)

Logs, screenshots, evidence

Timeline (2026-04-01 JST)

03/31 21:21  [health-monitor] restarting (reason: stale-socket)  ← first occurrence
04/01 00:21  [health-monitor] restarting (reason: stale-socket)
04/01 04:16  [health-monitor] restarting (reason: stale-socket)
04/01 04:51  [health-monitor] restarting (reason: stale-socket)
             [discord] client initialized ... awaiting gateway readiness  ← STUCK
04/01 05:05  Service restart (auto-update to 2026.3.28)
             [discord] logged in to discord as ...                        ← login OK
             [heartbeat] failed: Unknown Channel                          ← but ready never fires

Network evidence (from ss -tnip)

The Discord gateway WebSocket IS connected and exchanging data:

ESTAB  162.43.76.147:44734 → 162.159.134.234:443
  bytes_sent:2612  bytes_received:44044  data_segs_out:12  data_segs_in:22

44KB received is consistent with HELLO + READY + GUILD_CREATE payloads. Heartbeat ACKs continue flowing. But Carbon never emits the ready event.

Attempted fixes (none resolved)

• IPv4-first DNS (--dns-result-order=ipv4first)
• Disable IPv6 on eth0 (sysctl net.ipv6.conf.eth0.disable_ipv6=1)
• Disable autoSelectFamily via preload script
• Node.js v22 LTS downgrade (v22.22.2) — behavior changes slightly ("logged in" appears instead of "awaiting gateway readiness") but ready still never fires
• Clean delivery queue
• Multiple OpenClaw version changes (2026.3.24 ↔ 2026.3.28 ↔ 2026.3.31-beta.1)

Additional context

• Bot is in 2 guilds, token is valid (REST API works, GET /users/@me returns correct bot info)
• GET /gateway/bot returns session_start_limit.remaining: 976/1000
• Direct WebSocket test to gateway.discord.gg using the bundled ws library works perfectly (receives HELLO within ms)
• The remote relay (wss://r1.kanitama.dpdns.org) also fails to connect inside the gateway process, though it works when tested externally
• Server has no global IPv6 route (only Tailscale fd7a:: prefix), causing ETIMEDOUT/ENETUNREACH on IPv6 connection attempts — Telegram's fetch handler recovers via sticky IPv4 fallback, but Carbon/gateway WS does not

Impact and severity

Critical — Discord channel is completely non-functional. The bot cannot send or receive any messages. Telegram continues to work. The issue persists across service restarts and version changes. Manual intervention (beyond restart) cannot recover the Discord channel.

The stale-socket → stuck-ready chain seems deterministic once triggered. No self-recovery has been observed over multiple hours.