openclaw - ✅(Solved) Fix [Bug]: Silently lost connection to Slack [2 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#72808Fetched 2026-04-28 06:32:00
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
1
Author
Timeline (top)
cross-referenced ×2labeled ×2commented ×1

My slack connection to my openclaw had been working fine for several days. Today at lunch, I tried to demo to some friends and it never answered. Later when back at my desk, I sent more slack messages, and it still didn't answer. OTOH chatting through the web interface worked fine. Somehow the connection with Slack just silently stopped working.

Root Cause

I haven't tried to fix it (eg, by restarting). If you give me hints on how to debug, I can upload any logs or dig into the root cause.

Fix Action

Fixed

PR fix notes

PR #71550: feat(slack): expose channels.slack.logLevel so operators can silence socket-mode pong-timeout noise (#71531)

Description (problem / solution / changelog)

Closes #71531.

Bug

The bundled @slack/socket-mode 2.0.6 emits an unconditional WARN every ~30s when the periodic pong is late:

A pong wasn't received from the server before the timeout of 5000ms!

The library auto-reconnects cleanly, so the WARN is noise, not a failure signal — but it floods gateway.err.log and operators end up filtering it externally to recover signal-to-noise. The existing pingPongLoggingEnabled flag is already the default false in 2.0.6 but does NOT gate the pong-timeout WARN — it fires unconditionally in SlackWebSocket.js.

The only effective knob is bolt's App({ logLevel }) option, which gates ALL sub-library output. openclaw was not passing it, so bolt defaulted to INFO.

Fix

Add an optional channels.slack.logLevel knob (DEBUG | INFO | WARN | ERROR) and forward it to bolt's App constructor when set. When omitted, behavior is unchanged (bolt's INFO default).

channels:
  slack:
    logLevel: ERROR   # silences socket-mode pong-timeout WARNs

Diff

  • src/config/zod-schema.providers-core.ts — add logLevel to SlackConfigSchema
  • extensions/slack/src/monitor/provider-support.ts — accept + forward logLevel in createSlackBoltApp
  • extensions/slack/src/monitor/provider.ts — thread slackCfg.logLevel through
  • extensions/slack/src/monitor/provider.interop.test.ts — 2 new tests:
    • forwards logLevel to bolt's App when provided
    • omits logLevel when not set so bolt's INFO default is preserved

48 LOC across 4 files. Lint clean (pnpm oxlint — 0 warnings, 0 errors).

Out of scope

  • Per-account override (channels.slack.accounts.<id>.logLevel) — can be added later if needed; the channel-level knob covers the reported use case.
  • Per-sub-library filtering — bolt doesn't expose this granularity directly.
  • Custom logger injection — same.

🤖 generated with assistance from Claude Code Co-authored-by: HCL [email protected]

Changed files

  • extensions/slack/src/monitor/provider-support.ts (modified, +14/-0)
  • extensions/slack/src/monitor/provider.interop.test.ts (modified, +35/-0)
  • extensions/slack/src/monitor/provider.ts (modified, +5/-0)
  • src/config/types.slack.ts (modified, +8/-0)
  • src/config/zod-schema.providers-core.ts (modified, +6/-0)

PR #73162: fix(slack): remove socket reconnect attempt cap so gateway stays connected indefinitely

Description (problem / solution / changelog)

What and why

After 12 consecutive failed Slack socket reconnects the provider threw an error and exited permanently. The gateway never restarts providers after they exit, so all subsequent Slack messages were silently dropped while the bot still appeared online in Slack (bots always show green in Slack's UI regardless of socket state).

This is the root cause of #72808. Users who hit a network blip or Slack server restart at the wrong time would lose Slack entirely until they manually restarted OpenClaw.

Fix

Set maxAttempts: 0 in SLACK_SOCKET_RECONNECT_POLICY. The existing maxAttempts > 0 && guard in provider.ts already treats 0 as unlimited — this convention was clearly intentional given the || "∞" fallback already present in the log format strings.

Non-recoverable auth errors (account_inactive, invalid_auth, token_revoked, etc.) already bail immediately via isNonRecoverableSlackAuthError before the maxAttempts check runs, so removing the cap does not create an infinite retry loop for permanent credential failures.

With maxAttempts: 0 the reconnect log now reads retry N/∞ in Xs, which is the correct behavior for a long-running gateway service.

Testing

  • 813 Slack extension tests pass unchanged (no test asserted on maxAttempts behavior)
  • Extension prod + test typecheck lanes green

Fixes #72808

Changed files

  • extensions/slack/src/monitor/reconnect-policy.ts (modified, +1/-1)
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

My slack connection to my openclaw had been working fine for several days. Today at lunch, I tried to demo to some friends and it never answered. Later when back at my desk, I sent more slack messages, and it still didn't answer. OTOH chatting through the web interface worked fine. Somehow the connection with Slack just silently stopped working.

Steps to reproduce

  1. Run openclaw
  2. Connect slack
  3. Verify it works by sending DMs directly to the Slack App
  4. Wait a few days
  5. Try sending DMs directly to the Slack App, or tag it in a channel.

Expected behavior

It should reply over slack.

Actual behavior

It does not reply over slack.

OpenClaw version

v2026.4.19-beta.2

Operating system

macOS 26.2

Install method

I think npm, but I don't even remember for sure now.

Model

Qwen30b

Provider / routing chain

openclaw -> ollama -> quen

Additional provider/model setup details

No response

Logs, screenshots, and evidence

It shows the bot as "online" (green indicator): <img width="1166" height="226" alt="Image" src="https://github.com/user-attachments/assets/b6a36900-33f5-42f9-a890-0726592f7ede" />

but it ignores everything.

Impact and severity

Affected: Slack user Severity: blocks workflow Frequency: always (afaik) Consequence: cannot use, since Slack is my only method of communication with the bot

Additional information

I haven't tried to fix it (eg, by restarting). If you give me hints on how to debug, I can upload any logs or dig into the root cause.

extent analysis

TL;DR

The issue might be resolved by restarting the openclaw service or checking the connection settings between openclaw and Slack.

Guidance

  • Verify the Slack connection settings in openclaw to ensure they are correct and haven't changed.
  • Check the openclaw logs for any error messages related to the Slack connection.
  • Try restarting the openclaw service to see if it resolves the issue.
  • If the issue persists, try re-establishing the Slack connection in openclaw.

Example

No code snippet is provided as there is no clear indication of a specific code-related issue.

Notes

The issue seems to be related to the connection between openclaw and Slack, but the root cause is unclear. Further debugging and log analysis may be necessary to determine the exact cause.

Recommendation

Apply workaround: Restart the openclaw service and re-check the Slack connection settings, as this may resolve the issue without requiring an upgrade or code changes.

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…

FAQ

Expected behavior

It should reply over slack.

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 [Bug]: Silently lost connection to Slack [2 pull requests, 1 comments, 2 participants]