Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Unhandled promise rejection on Slack WebSocket 408 crashes gateway [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#69607•Fetched 2026-04-22 07:50:18
View on GitHub
Comments
1
Participants
2
Timeline
1
Reactions
0
Author
hansic21hansic21
Participants
hansic21hansic21mjamivmjamiv
Timeline (top)
commented ×1

When the Slack Socket Mode WebSocket disconnects with an unexpected server response (e.g., 408), the gateway process crashes with Unhandled promise rejection: undefined instead of letting the existing health-monitor / retry logic recover.

Error Message

Production log excerpt (UTC):

Root Cause

Process crashed at 02:52 UTC, and because the container start command backgrounds a git-sync loop alongside `exec node src/server.js`, Railway's `ON_FAILURE` restart policy did not fire (container remained "alive"). Gateway was down ~2 hours until manually redeployed.

Fix Action

Fix / Workaround

Temporary mitigation (our side)

Set `NODE_OPTIONS=--unhandled-rejections=warn` to downgrade unhandled rejections from fatal to a warning so the process survives and the internal recovery logic can take over. This is a workaround, not a fix.

Happy to provide more logs or test a patch.

Code Example

02:52:03 [WARN] socket-mode:SlackWebSocket:688 A pong wasn't received ... timeout 5000ms
02:52:20 [WARN] socket-mode:SlackWebSocket:689 A pong wasn't received ...
02:52:35 [WARN] socket-mode:SlackWebSocket:690 A pong wasn't received ...
02:52:49 [ERROR] socket-mode:SlackWebSocket:691 WebSocket error occurred: Unexpected server response: 408
02:52:49 [ERROR] socket-mode:SocketModeClient:681 WebSocket error! Error: Unexpected server response: 408
02:52:49 [slack] socket disconnected (error). retry 1/12 in 2s (Unexpected server response: 408)
02:52:49 [openclaw] Unhandled promise rejection: undefined
[gateway] exited code=1 signal=null
RAW_BUFFERClick to expand / collapse

Summary

When the Slack Socket Mode WebSocket disconnects with an unexpected server response (e.g., 408), the gateway process crashes with Unhandled promise rejection: undefined instead of letting the existing health-monitor / retry logic recover.

Environment

  • openclaw npm package: v2026.3.22
  • Node: 24.x (Railway runtime)
  • Deployment: clawdbot-railway-template (vignesh07) on Railway
  • Providers: 6 Slack workspaces (default/rhythm/hbs/huri/nari/tori)

Observed behavior

Production log excerpt (UTC):

02:52:03 [WARN] socket-mode:SlackWebSocket:688 A pong wasn't received ... timeout 5000ms
02:52:20 [WARN] socket-mode:SlackWebSocket:689 A pong wasn't received ...
02:52:35 [WARN] socket-mode:SlackWebSocket:690 A pong wasn't received ...
02:52:49 [ERROR] socket-mode:SlackWebSocket:691 WebSocket error occurred: Unexpected server response: 408
02:52:49 [ERROR] socket-mode:SocketModeClient:681 WebSocket error! Error: Unexpected server response: 408
02:52:49 [slack] socket disconnected (error). retry 1/12 in 2s (Unexpected server response: 408)
02:52:49 [openclaw] Unhandled promise rejection: undefined
[gateway] exited code=1 signal=null

Earlier the same morning (02:21 and 02:46 UTC), stale-socket detections were handled gracefully by the health-monitor — provider was restarted and recovered. The 02:52 case differs only in that the WebSocket error path was hit; that path appears to leave a promise unhandled.

Expected

WebSocket errors should be caught and routed to the existing retry / health-monitor logic (same as stale-socket), not crash the process.

Impact

Process crashed at 02:52 UTC, and because the container start command backgrounds a git-sync loop alongside `exec node src/server.js`, Railway's `ON_FAILURE` restart policy did not fire (container remained "alive"). Gateway was down ~2 hours until manually redeployed.

Temporary mitigation (our side)

Set `NODE_OPTIONS=--unhandled-rejections=warn` to downgrade unhandled rejections from fatal to a warning so the process survives and the internal recovery logic can take over. This is a workaround, not a fix.

Suggested fix

Add a `.catch()` (or try/await) on whichever promise is left dangling in the Slack WebSocket error handler — likely in the reconnect path after `socket-mode:SocketModeClient` emits an error.

Happy to provide more logs or test a patch.

extent analysis

TL;DR

Add a .catch() block to the Slack WebSocket error handler to catch and handle the unhandled promise rejection.

Guidance

  • Identify the promise that is being left unhandled in the Slack WebSocket error handler, likely in the reconnect path after socket-mode:SocketModeClient emits an error.
  • Add a .catch() block to handle the error and route it to the existing retry/health-monitor logic.
  • Verify that the .catch() block is correctly handling the error by testing the WebSocket error path.
  • Consider adding additional logging to help diagnose any future issues with the WebSocket error handler.

Example

// Example of adding a .catch() block to handle the error
socketModeClient.on('error', (error) => {
  // existing error handling code
}).catch((error) => {
  // handle the error and route it to the existing retry/health-monitor logic
  console.error('Error in Slack WebSocket error handler:', error);
  // retry or health-monitor logic here
});

Notes

The provided temporary mitigation of setting NODE_OPTIONS=--unhandled-rejections=warn can help prevent the process from crashing, but it is not a permanent fix. A proper fix should involve adding error handling to the Slack WebSocket error handler.

Recommendation

Apply the suggested fix by adding a .catch() block to the Slack WebSocket error handler, as this will properly handle the unhandled promise rejection and prevent the process from crashing.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#permission error#memory optimization#batch processing#GPU compatibility#latency issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix Unhandled promise rejection on Slack WebSocket 408 crashes gateway [1 comments, 2 participants]