PR #68253: fix(slack): opt out of stale-socket health-monitor (Socket Mode owns liveness)

• Repository: openclaw/openclaw
• Author: mjamiv
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/68253

Description (problem / solution / changelog)

Summary

Slack Socket Mode bots were being restarted by the gateway every ~35 minutes on idle — even when the WebSocket was fully healthy, Slack's server pings were flowing, and the bot was simply waiting for the next message. The fix opts the Slack channel out of the gateway's stale-socket heuristic, since @slack/socket-mode already runs its own liveness deadman. A latent bug in the status-adapter factory that silently dropped this opt-out field for any plugin is fixed at the same time, so the existing Telegram opt-out now works for the right reason rather than by coincidence.

Fixes #61072, #64009, #58540.

Problem

evaluateChannelHealth in src/gateway/channel-health-policy.ts restarts any channel whose lastEventAt is older than channelStaleEventThresholdMinutes (default 30). In the Slack plugin, lastEventAt is bumped only on user-facing Slack events — message, app_mention, reactions, member/channel/pin events. Socket Mode envelopes like hello, the raw WebSocket ping/pong frames that Slack sends every ~30s, and the internal deadman that the library runs on outgoing pings are not surfaced as slack_event emissions and therefore never advance the counter.

On a quiet DM bot (e.g. a one-owner personal bot) this triggers spurious restarts every 30 min + up to one 5-min health-check tick. In production on one tenant I observed 22 such restarts in an 8-hour window, each causing a ~1-2s offline interval, a Socket Mode reconnect, and occasional dropped DMs (see #58540).

Why the current behavior is wrong for Slack

The @slack/socket-mode client already maintains its own liveness signal independently of anything the gateway does:

• Server pings — Slack emits ping frames roughly every 30s (serverPingTimeoutMS=30000). If the client stops receiving them, the library reconnects on its own.
• Client pings — the library itself pings the server and expects a pong within clientPingTimeoutMS=5000; three consecutive missed pongs force an internal reconnect.
• On real disconnects, the library emits disconnecting → disconnected, which flows into the plugin's runtime state, sets snapshot.connected = false, and is handled by the separate connected === false branch of evaluateChannelHealth. That branch still restarts the channel.

So the stale-socket check in the gateway is a second, weaker liveness signal that only fires on a heuristic (no user event in 30 min) that doesn't correlate with socket health. For Slack specifically, opting out of it removes a source of false positives without removing any real-failure coverage.

What changed

1. extensions/slack/src/channel.ts — sets skipStaleSocketHealthCheck: true on the Slack status adapter, with an inline comment explaining why. Mirrors what extensions/telegram/src/channel.ts already declares.
2. src/plugin-sdk/status-helpers.ts — createComputedAccountStatusAdapter and createAsyncComputedAccountStatusAdapter now forward skipStaleSocketHealthCheck from the options onto the returned adapter. Both factories previously whitelisted their output fields and silently dropped this one. The field is already declared on ChannelStatusAdapter (see src/channels/plugins/types.adapters.ts) and is read by the health monitor via getChannelPlugin(channelId)?.status?.skipStaleSocketHealthCheck.
3. src/plugin-sdk/status-helpers.test.ts — regression test that verifies the flag round-trips through both the sync and async factory, plus a negative case.

Out of scope: no change to the health monitor, the stale-socket branch itself, or the Telegram opt-out (other than the factory now propagating the flag it has always accepted). No behavior change for any plugin that does not set skipStaleSocketHealthCheck: true.

A note on Telegram

extensions/telegram/src/channel.ts has had skipStaleSocketHealthCheck: true for a while. Before this patch that line was effectively a no-op, because the factory dropped it. Telegram isn't affected in practice, because long-polling never sets snapshot.connected === true, so the stale-socket branch is skipped on a different condition (snapshot.connected === true must hold). With the factory fix Telegram's existing opt-out starts working for the reason its comment implies it should.

Testing

• New unit tests in src/plugin-sdk/status-helpers.test.ts cover both factories and both presence/absence of the flag.
  • npx vitest run src/plugin-sdk/status-helpers.test.ts → 23 passed.
• Existing Slack tests unaffected: npx vitest run extensions/slack/src/channel.test.ts → 26 passed.
• Production validation: applied the equivalent patch to a 4.11 deployment running an idle Slack DM bot; set channelStaleEventThresholdMinutes: 1 and health-check interval=60s (aggressive worst case). Ran 8+ minutes idle with zero stale-socket events. Pre-patch under default 30/5 settings, the same bot had been averaging one spurious restart every ~35 min (22 over 8h).

Compatibility

• No config changes. Default behavior for Slack shifts from "spurious restarts on idle" to "no spurious restarts on idle." Real socket failures still restart via the connected === false branch, which is unchanged.
• No public API changes. The ChannelStatusAdapter.skipStaleSocketHealthCheck field was already exported and already read by the health monitor; this PR just closes the factory gap.
• No plugin opt-in needed. Slack already has the opt-out in this PR; Telegram has always had it.

Test plan (for reviewers)

• Unit: npx vitest run src/plugin-sdk/status-helpers.test.ts
• Unit: npx vitest run extensions/slack/src/channel.test.ts
• Idle-bot repro: configure a Slack bot, leave it untouched for ~45 min with default settings, confirm no [health-monitor] ... reason: stale-socket lines in the gateway log.
• Real-disconnect check: briefly block outbound traffic to wss-primary.slack.com, confirm the library emits disconnected and the connected === false branch triggers a restart (i.e. we didn't accidentally silence genuine failures).

Related issues

• #61072 — originally reported symptom (~39-min restart cadence)
• #64009 — "Slack socket-mode connection becomes stale, misses ping/pong, and restarts repeatedly"
• #58540 — downstream impact: Slack DM not triggered after stale-socket reconnect
• #65632 — open Discord PR taking the same opt-out approach for a sibling channel
• #38643 / #39083 — earlier stale-socket work that seeded lastEventAt on connect but did not close the post-connect gap

Changed files

• extensions/slack/src/channel.ts (modified, +11/-0)
• src/plugin-sdk/status-helpers.test.ts (modified, +46/-0)
• src/plugin-sdk/status-helpers.ts (modified, +2/-0)