Bug Description

Discord health-monitor frequently triggers restarting (reason: stale-socket) and occasionally coincides with actual BOOT/restart notifications, but this does not appear to be a simple v2026.3.24-only regression.

After deeper log review, the underlying Discord socket instability (stale-socket and websocket close code 1005) has existed since at least 2026-03-17. What is unclear from current logs is which restart actions are provider/channel-level recoveries versus full gateway restarts.

Why this issue is important

The problem is easy to underestimate because service usually self-recovers quickly, so Discord may appear responsive most of the time. But the logs show chronic health-monitor intervention over many days.

This creates three practical problems:

1. Frequent Discord connection recovery actions indicate unhealthy long-lived socket stability.
2. Some events now appear to coincide with BOOT.md restart notifications, suggesting at least some recovery paths escalate beyond simple socket reconnects.
3. Current logs do not make it easy to distinguish:
   • provider-level reconnect/restart
   • channel-level restart
   • full gateway process restart

Environment

• OpenClaw version currently observed: 2026.3.24 (cff6dc9)
• Node: v25.8.1
• OS: Darwin 25.3.0 (arm64)
• Channels configured: Discord + Feishu
• Gateway managed via LaunchAgent on macOS

Observed Symptoms

Long-running Discord instability

The following patterns appear repeatedly in logs over multiple days:

[health-monitor] [discord:default] health-monitor: restarting (reason: stale-socket)
[discord] gateway: WebSocket connection closed with code 1005

Important clarification

This is not just a one-day issue after upgrading to 2026.3.24.

Historical evidence shows repeated stale-socket and code 1005 events since 2026-03-17.

Today’s stronger symptom

On 2026-03-26, the user reports receiving multiple BOOT.md gateway-restart notifications on Feishu. That suggests at least some of these health-monitor recovery events are reaching the restart-notification path, not just silently reconnecting a Discord socket.

Log Evidence

Examples of repeated stale-socket recoveries

2026-03-26T00:22:36.826+08:00 [health-monitor] [discord:default] health-monitor: restarting (reason: stale-socket)
2026-03-26T00:57:36.833+08:00 [health-monitor] [discord:default] health-monitor: restarting (reason: stale-socket)
2026-03-26T01:32:36.846+08:00 [health-monitor] [discord:default] health-monitor: restarting (reason: stale-socket)
2026-03-26T02:27:36.874+08:00 [health-monitor] [discord:default] health-monitor: restarting (reason: stale-socket)
2026-03-26T03:02:36.917+08:00 [health-monitor] [discord:default] health-monitor: restarting (reason: stale-socket)
2026-03-26T03:37:36.942+08:00 [health-monitor] [discord:default] health-monitor: restarting (reason: stale-socket)
2026-03-26T04:12:36.967+08:00 [health-monitor] [discord:default] health-monitor: restarting (reason: stale-socket)
2026-03-26T04:47:36.981+08:00 [health-monitor] [discord:default] health-monitor: restarting (reason: stale-socket)
2026-03-26T05:22:37.002+08:00 [health-monitor] [discord:default] health-monitor: restarting (reason: stale-socket)
2026-03-26T05:57:37.021+08:00 [health-monitor] [discord:default] health-monitor: restarting (reason: stale-socket)
2026-03-26T06:42:37.046+08:00 [health-monitor] [discord:default] health-monitor: restarting (reason: stale-socket)
2026-03-26T09:37:15.419+08:00 [health-monitor] [discord:default] health-monitor: restarting (reason: stale-socket)
2026-03-26T10:12:21.075+08:00 [health-monitor] [discord:default] health-monitor: restarting (reason: stale-socket)
2026-03-26T11:17:27.190+08:00 [health-monitor] [discord:default] health-monitor: restarting (reason: stale-socket)
2026-03-26T12:51:08.554+08:00 [health-monitor] [discord:default] health-monitor: restarting (reason: stale-socket)

Matching websocket closures

[discord] gateway: WebSocket connection closed with code 1005

These also appear repeatedly across earlier days.

Historical scope

The same stale-socket / code-1005 pattern is visible back to 2026-03-17, so this should not be framed as a cleanly isolated regression introduced only in 2026.3.24.

Current Assessment

This looks like a chronic Discord socket health problem and/or overly aggressive stale-socket detection, with recovery behavior that is insufficiently observable.

The key unresolved question is:

When health-monitor logs restarting, what is actually being restarted?

The current behavior makes it difficult to tell whether a given recovery event is:

• only reconnecting the Discord websocket
• restarting the Discord provider/channel
• or escalating into a full gateway restart

Because BOOT.md notifications were observed today, at least some events appear to reach a deeper restart path.

Expected Behavior

1. Health-monitor should expose more precise diagnostics for Discord socket health.
2. Logs should clearly distinguish:
   • websocket reconnect
   • provider/channel restart
   • full gateway restart
3. stale-socket detection should avoid excessive false positives if the connection is still recoverable.
4. Restart-notification paths should be traceable so operators can tell whether BOOT.md notifications correspond to actual process restarts.

Suggested Improvements

• Include additional structured diagnostics when stale-socket is detected:
  • socket state
  • last inbound activity timestamp
  • ping/pong timing
  • reconnect attempt count
• Log explicit recovery mode labels, e.g.:
  • discord-reconnect
  • provider-restart
  • gateway-restart
• Clarify whether code 1005 should be treated as expected transient behavior or restart-worthy failure.

Why I’m filing this

Even though the bot usually remains responsive, the health-monitor is intervening frequently enough that operators cannot tell whether the system is healthy or repeatedly self-recovering from a latent Discord transport issue.