Environment

• OpenClaw version: 2026.3.8 (3caab92)
• Platform: Linux x64 / Node 22.22.0
• Channel: Slack (Socket Mode)

Summary

After a health-monitor-triggered socket restart, the Slack WebSocket connection experienced a pong timeout followed by a HTTP 408 error, which triggered an Unhandled promise rejection: undefined in the gateway process.

Timeline (all UTC, 2026-03-11)

Relevant log entries (structured, PII redacted)

{"0":"[WARN]  socket-mode:SlackWebSocket:53 A pong wasn't received from the server before the timeout of 5000ms!","_meta":{"date":"2026-03-11T21:48:32.309Z","logLevelName":"WARN","path":{"fileNameWithLine":"subsystem-kzdGVyce.js:945","method":"console.warn"}}}

{"0":"[ERROR]  socket-mode:SlackWebSocket:58 WebSocket error occurred: Unexpected server response: 408","_meta":{"date":"2026-03-11T21:49:23.801Z","logLevelName":"ERROR","path":{"fileNameWithLine":"subsystem-kzdGVyce.js:946","method":"console.error"}}}

{"0":"[ERROR]  socket-mode:SocketModeClient:52 WebSocket error! Error: Unexpected server response: 408","_meta":{"date":"2026-03-11T21:49:23.803Z","logLevelName":"ERROR","path":{"fileNameWithLine":"subsystem-kzdGVyce.js:946","method":"console.error"}}}

{"0":"{\"subsystem\":\"gateway/channels/slack\"}","1":"slack socket disconnected (error). retry 1/12 in 2s (Unexpected server response: 408)","_meta":{"date":"2026-03-11T21:49:23.818Z","logLevelName":"ERROR","path":{"fileNameWithLine":"subsystem-kzdGVyce.js:1112"}}}

{"0":"[openclaw] Unhandled promise rejection: undefined","_meta":{"date":"2026-03-11T21:49:23.825Z","logLevelName":"ERROR","path":{"fileNameWithLine":"subsystem-kzdGVyce.js:946","method":"console.error"}}}

Root cause hypothesis

The Unhandled promise rejection: undefined fires from subsystem-kzdGVyce.js:946 — the same line as the console.error WebSocket error handler. The rejection value is undefined, suggesting the error handler itself is either throwing or returning a rejected promise without a value. This is likely a missing .catch() on a promise inside the WebSocket error callback.

The process did not crash in this instance (the retry loop continued), but an unhandled rejection under different timing or Node.js --unhandled-rejections=throw mode could terminate the process.

Secondary request

When the socket recovers after a gap (health-monitor restart or retry success), it would be helpful to emit a brief user-visible notification so the operator knows there was a period of disconnection. Currently there is no signal to the user that the gateway was offline.

Steps to reproduce

Difficult to reproduce on demand — requires Slack's server returning a 408 after a pong timeout. The health-monitor stale-socket restart appears to be a prerequisite; the second disconnect occurred ~23 minutes after the first reconnect.