openclaw - ✅(Solved) Fix Slack provider hardcodes autoReconnectEnabled: false, defeats native socket-mode reconnect [1 pull requests, 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#77933Fetched 2026-05-06 06:19:11
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
2
Timeline (top)
commented ×1cross-referenced ×1

The Slack provider hardcodes autoReconnectEnabled: false on the Bolt SocketModeReceiver, which defeats @slack/socket-mode's native WebSocket reconnect on pong timeout. Every pong miss → full receiver rebuild instead of a cheap socket-level reconnect, producing observable disconnect storms.

Error Message

On this install, Slack websockets persistently disconnect every ~30–45s with pong timeouts. The disconnects persist even when CPU is idle (~9%), so this is not just an event-loop blocking symptom — it's a separate root cause.

Root Cause

On this install, Slack websockets persistently disconnect every ~30–45s with pong timeouts. The disconnects persist even when CPU is idle (~9%), so this is not just an event-loop blocking symptom — it's a separate root cause.

Fix Action

Fixed

PR fix notes

PR #78158: [AI-assisted] fix(slack): enable native socket reconnect

Description (problem / solution / changelog)

Summary

  • Keep Slack Socket Mode's native reconnect enabled on SocketModeReceiver.
  • Update the focused Slack interop expectations and changelog entry.

Fixes #77933.

Real behavior proof

Behavior or issue addressed: Slack Socket Mode was constructed with autoReconnectEnabled: false, so pong timeouts could not use the Slack SDK's native socket reconnect path and instead pushed recovery back toward heavier OpenClaw provider rebuild behavior.

Real environment tested: Local Windows checkout of this PR branch at commit 08bec49b97, using Node/pnpm from the repository toolchain.

Exact steps or command run after this patch: Inspected the patched createSlackBoltApp options and ran git diff --check, corepack pnpm exec oxfmt --check --threads=1 extensions/slack/src/monitor/provider-support.ts extensions/slack/src/monitor/provider.interop.test.ts extensions/slack/src/monitor/provider.reconnect.test.ts CHANGELOG.md, corepack pnpm test extensions/slack/src/monitor/provider.interop.test.ts extensions/slack/src/monitor/provider.reconnect.test.ts extensions/slack/src/config-schema.test.ts, and corepack pnpm check:changed.

Evidence after fix: Terminal/diff capture from the patched checkout shows the Slack SDK option now enables native reconnect:

extensions/slack/src/monitor/provider-support.ts
autoReconnectEnabled: true,

extensions/slack/src/monitor/provider.interop.test.ts
uses SocketModeReceiver with native reconnects and shared client options
autoReconnectEnabled: true

The focused Slack test shard also passed:

Test Files  3 passed (3)
Tests       40 passed (40)

Observed result after fix: createSlackBoltApp now passes autoReconnectEnabled: true to SocketModeReceiver, and the focused Slack interop/reconnect/config-schema tests pass with the native reconnect expectation.

What was not tested: I did not run a live Slack workspace disconnect/pong-timeout session. This proof is source-level plus focused Slack provider regression coverage.

Validation

  • git diff --check
  • corepack pnpm exec oxfmt --check --threads=1 extensions/slack/src/monitor/provider-support.ts extensions/slack/src/monitor/provider.interop.test.ts extensions/slack/src/monitor/provider.reconnect.test.ts CHANGELOG.md
  • corepack pnpm test extensions/slack/src/monitor/provider.interop.test.ts extensions/slack/src/monitor/provider.reconnect.test.ts extensions/slack/src/config-schema.test.ts
  • corepack pnpm check:changed

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/slack/src/monitor/provider-support.ts (modified, +1/-1)
  • extensions/slack/src/monitor/provider.interop.test.ts (modified, +3/-3)

Code Example

function createSlackBoltApp(params) {
  const receiver = params.slackMode === "socket" ? new params.interop.SocketModeReceiver({
    appToken: params.appToken ?? "",
    autoReconnectEnabled: false,                              // ← hardcoded
    installerOptions: { clientOptions: params.clientOptions }
  }) : new params.interop.HTTPReceiver({ ... });
  ...
}
RAW_BUFFERClick to expand / collapse

Summary

The Slack provider hardcodes autoReconnectEnabled: false on the Bolt SocketModeReceiver, which defeats @slack/socket-mode's native WebSocket reconnect on pong timeout. Every pong miss → full receiver rebuild instead of a cheap socket-level reconnect, producing observable disconnect storms.

Reproduction

In dist/extensions/slack/provider-LUGHR724.js:1755 (and presumably the corresponding source file):

function createSlackBoltApp(params) {
  const receiver = params.slackMode === "socket" ? new params.interop.SocketModeReceiver({
    appToken: params.appToken ?? "",
    autoReconnectEnabled: false,                              // ← hardcoded
    installerOptions: { clientOptions: params.clientOptions }
  }) : new params.interop.HTTPReceiver({ ... });
  ...
}

Observed behavior

On this install, Slack websockets persistently disconnect every ~30–45s with pong timeouts. The disconnects persist even when CPU is idle (~9%), so this is not just an event-loop blocking symptom — it's a separate root cause.

When autoReconnectEnabled: false, the SocketModeClient does not auto-reconnect; the gateway must rebuild the receiver from scratch on every disconnect, which is heavier and racier than the library's native reconnect.

Impact

  • Constant Slack channel flap (DMs delayed/lost, message ordering issues).
  • Increased load on the gateway during reconnect bursts.
  • Compounds with other transient pressure (LLM call hangs, session pile-ups) — receiver rebuilds queue up while the gateway is already saturated.

Proposed fix

Either:

  1. Change the hardcoded value: autoReconnectEnabled: true.
  2. Plumb it as a config option with true default: slack.socketMode.autoReconnect (or similar).

@slack/socket-mode documents autoReconnectEnabled: true as the recommended default. The current hardcoded false is the unsafe value.

Environment

  • OpenClaw installed from npm at /opt/homebrew/lib/node_modules/openclaw/ (macOS, M-series, node v22)
  • @slack/bolt + @slack/socket-mode (versions per package.json — pinned by openclaw)
  • Diagnostic timestamp: 2026-05-05

extent analysis

TL;DR

Enable auto-reconnect for the Slack SocketModeReceiver by setting autoReconnectEnabled to true.

Guidance

  • Review the createSlackBoltApp function in dist/extensions/slack/provider-LUGHR724.js and update the autoReconnectEnabled parameter to true.
  • Consider adding a config option to control the autoReconnectEnabled value, allowing for flexibility in different environments.
  • Verify the change by monitoring the Slack websocket disconnects and reconnects, ensuring that the disconnect storms are resolved.
  • Check the @slack/socket-mode documentation for any additional recommendations or guidelines on using autoReconnectEnabled.

Example

function createSlackBoltApp(params) {
  const receiver = params.slackMode === "socket" ? new params.interop.SocketModeReceiver({
    appToken: params.appToken ?? "",
    autoReconnectEnabled: true, // updated value
    installerOptions: { clientOptions: params.clientOptions }
  }) : new params.interop.HTTPReceiver({ ... });
  ...
}

Notes

The proposed fix assumes that the autoReconnectEnabled parameter is the primary cause of the disconnect storms. However, additional factors may contribute to the issue, and further investigation may be necessary to fully resolve the problem.

Recommendation

Apply the workaround by setting autoReconnectEnabled to true, as this is the recommended default value according to the @slack/socket-mode documentation.

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…

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 - ✅(Solved) Fix Slack provider hardcodes autoReconnectEnabled: false, defeats native socket-mode reconnect [1 pull requests, 1 comments, 2 participants]