Summary
Control UI with a stale/expired gateway auth token retries WebSocket connection every ~16 seconds indefinitely, instead of stopping and prompting the user to re-enter the token. Combined with chat.history appearing to block the Node.js event loop for ~12 seconds, this causes Slack Socket Mode pong timeouts and repeated socket disconnects.
Steps to Reproduce
- Have Slack channel running via Socket Mode
- Open Control UI in a browser tab
- Gateway restarts (or token rotates for any reason)
- Control UI now has a stale token
Observed Behavior
- Control UI retries WebSocket auth every ~16 seconds with
token_mismatch — never stops, never prompts user
chat.history WebSocket handler takes ~12-13 seconds to complete- During that ~12s window, the Node.js event loop appears blocked — Slack WebSocket pong responses cannot be sent
- Slack SDK fires pong timeout (5000ms) → socket disconnect → reconnect takes 35-40 seconds
- Any Slack messages sent during disconnect windows are delayed until reconnection
- Net effect: simple Slack DMs take 50-110+ seconds to get a response, even though model latency is ~3 seconds
Evidence Pattern
On every gateway restart, chat.history completion and Slack pong timeout occur within 1-3ms of each other:
[ws] chat.history completed (12667ms) ← 13:06:24.895
[WARN] pong not received before 5000ms! ← 13:06:24.898
This pattern was consistent across 4 consecutive restarts.
Expected Behavior
- Control UI should stop retrying on auth failure and display a clear "token expired — please re-enter" message instead of silently looping every 16 seconds
chat.history should not block the event loop — 12+ seconds of synchronous work on what should be a local operation is excessive and starves other WebSocket connections (Slack, Telegram) of pong responses- A UI authentication issue should never be able to degrade channel connectivity
Workaround
Closing the Control UI browser tabs immediately resolved the issue — Slack response time dropped from ~57 seconds to ~7 seconds.
Environment
- OpenClaw v2026.4.24
- Node.js v24.13.1
- Slack channel in Socket Mode
- Linux (Fedora)
Summary
Control UI with a stale/expired gateway auth token retries WebSocket connection every ~16 seconds indefinitely, instead of stopping and prompting the user to re-enter the token. Combined with
chat.historyappearing to block the Node.js event loop for ~12 seconds, this causes Slack Socket Mode pong timeouts and repeated socket disconnects.Steps to Reproduce
Observed Behavior
token_mismatch— never stops, never prompts userchat.historyWebSocket handler takes ~12-13 seconds to completeEvidence Pattern
On every gateway restart,
chat.historycompletion and Slack pong timeout occur within 1-3ms of each other:This pattern was consistent across 4 consecutive restarts.
Expected Behavior
chat.historyshould not block the event loop — 12+ seconds of synchronous work on what should be a local operation is excessive and starves other WebSocket connections (Slack, Telegram) of pong responsesWorkaround
Closing the Control UI browser tabs immediately resolved the issue — Slack response time dropped from ~57 seconds to ~7 seconds.
Environment