Summary

After a channel stop exceeded 5000ms after abort; continuing shutdown log line, the Slack provider stops logging anything for hours and stops dispatching inbound events. The gateway process stays alive, /health returns OK, but Slack messages to the bot are silently dropped. The only known recovery is a manual gateway restart.

This is a distinct failure mode from #56508 — PR #56646 closed the clean-stop race by setting shuttingDown=true before app.stop(), but the forced-shutdown branch (when the abort itself times out at 5s) still leaves the adapter in a half-dead state where the dying retry timer fires once more and the new adapter never starts.

Environment

• OpenClaw 2026.4.26 (be8c246)
• macOS 14 (arm64), Node v25.9.0
• Bundled @slack/[email protected]

Reproduction (naturally occurring)

1. Pong-timeout cycle starts (common during the ~30-min stale-socket cadence on macOS / Node 25, see #61072)
2. Adapter starts its internal retry loop: retry 1/12 in 2s, 2/12, 3/12, 4/12 …
3. Health-monitor decides the socket is disconnected and calls stopChannel → gracefulStop
4. Graceful stop times out: [slack] [default] channel stop exceeded 5000ms after abort; continuing shutdown
5. The dying adapter's retry timer still fires one more time (e.g. retry 5/12 in 21s (undefined))
6. No further [slack] log entries for hours. New adapter is never observed. /health remains green.

Verbatim log trace

2026-04-30T19:14:09 [WARN] socket-mode:SlackWebSocket A pong wasn't received from the server before the timeout of 5000ms!
2026-04-30T19:14:13 [slack] socket disconnected (disconnect). retry 1/12 in 2s
2026-04-30T19:14:26 [slack] socket mode failed to start. retry 2/12 in 4s (undefined)
2026-04-30T19:14:41 [slack] socket mode failed to start. retry 3/12 in 7s (undefined)
2026-04-30T19:14:59 [slack] socket mode failed to start. retry 4/12 in 13s (undefined)
2026-04-30T19:15:15 [health-monitor] [slack:default] health-monitor: restarting (reason: disconnected)
2026-04-30T19:15:20 [slack] [default] channel stop exceeded 5000ms after abort; continuing shutdown
2026-04-30T19:15:22 [slack] socket mode failed to start. retry 5/12 in 21s (undefined)
[next "[slack] socket mode connected" entry: 2026-05-01T08:49:28 — 13 hours later, only after manual `launchctl kickstart -k`]

Diagnosis

After the abort-timeout forces shutdown to "continue":

• The dying adapter's retry timer is not cleared — it fires once more (retry 5/12)
• After that single fire, shuttingDown=true is presumably set, so the close handler does not schedule another retry
• The new adapter is not instantiated — there is no subsequent socket mode connected, no starting provider, no error of any kind

Net result: state is "old adapter half-stopped, new adapter never created". The gateway looks healthy because the gateway is healthy — only the slack subsystem is silently dead.

Suggested fixes

• When the abort-timeout fires and shutdown is forced to continue, explicitly cancel the dying adapter's retry timer so it cannot fire after shuttingDown=true — the retry 5/12 line is the last thing before silence
• Guarantee that a new adapter is instantiated even when stop() errored or timed out, not only when it returned cleanly
• Add an internal watchdog: if stopChannel succeeds but no socket mode connected arrives within N seconds, force a full restart from the gateway side rather than silently leaving the channel offline

Workarounds in place locally

• gateway.channelStaleEventThresholdMinutes 30 → 120 (per #61072) to reduce how often health-monitor triggers stopChannel, which is when the bug fires
• gateway.channelMaxRestartsPerHour 10 → 3 (defensive)
• Local hourly diagnostic alert: "no [slack] socket mode connected log for >2 hours" — would have caught the 13-hour silence in our case within ~1 hour, instead of users noticing later

Related

• #56508 (closed) — sibling failure mode in the clean-stop path
• PR #56646 (merged) — partial fix; covers gracefulStop() clean path only
• #61072 (open) — periodic stale-socket restarts on macOS arm64 / Node 25, the trigger
• #58519 (open) — event-loop starvation, root cause of the pong-timeouts that start the cycle