openclaw - 💡(How to fix) Fix Slack invalid_auth (revoked token) still crash-loops the whole gateway on 2026.5.20 — main-only fix (#81010) never shipped to a release

Summary

On [email protected], a single Slack channel auth failure (here: a revoked Slack bot token -> invalid_auth) crashes the entire gateway process (status=1/FAILURE), taking every other channel (Telegram, WhatsApp) down on each systemd restart, and crash-loops indefinitely.

This is the same crash class as #81010 ("Channel-plugin WebSocket errors crash the entire gateway process") and #6867 ("Slack invalid_auth during reconnection causes gateway crash"). #81010 was closed as "already implemented in main… the latest stable tag v2026.5.7 does not contain the proof commit", and #6867 is closed/not_planned. I'm opening a fresh report because the fix has still not reached an installable release — 2026.5.20 (well after v2026.5.7) still crashes — and both prior issues are closed (#81010 is also locked, so it can't be reopened/commented).

Version / env

• [email protected] (e510042), Node 24.15.0, Linux arm64 (Raspberry Pi), systemd --user service.
• Slack channel in socket mode.
• Bundled @slack/socket-mode at .../@slack/socket-mode/dist/src/errors.js (the throw site).

Confirmation the main containment is NOT in 2026.5.20

Grepping the installed dist for the channel-task containment / unrecoverable-start handling described in #81010's closing note returns zero matches:

$ grep -rl 'channel task exited|catchChannelTask|isolateChannel|UnrecoverableSocketModeStartError' \
    .../[email protected]/node_modules/openclaw/dist | wc -l
0

…while the crashing sendWhileNotReadyError path is present and reachable.

Live signature (2026.5.20)

[ERROR]  bolt-app Error: An API error occurred: invalid_auth
  data: { ok: false, error: 'invalid_auth', response_metadata: {} }
socket-mode:socket-mode An unhandled error occurred while Bolt processed (type: event_callback, error: Error: An API error occurred: invalid_auth)
    at sendWhileNotReadyError (.../@slack/socket-mode/dist/src/errors.js:66:26)
[slack] channel resolve failed; using config entries. ... slack error: invalid_auth
systemd: openclaw-gateway.service: Main process exited, code=exited, status=1/FAILURE
systemd: openclaw-gateway.service: Scheduled restart job, restart counter is at N.

Over ~3 days: ~1650 invalid_auth events with repeated status=1/FAILURE restarts (systemd NRestarts climbing on an otherwise active unit). Note the [slack] channel resolve failed; using config entries line — the initial auth.test failure is caught and swallowed, and the channel proceeds to start the socket anyway, which then throws.

Reproduction

1. Configure a Slack channel (socket mode) with a bot token.
2. Revoke/invalidate the bot token (or the app-level xapp- token).
3. Start the gateway. It logs invalid_auth, throws sendWhileNotReadyError uncaught, exits 1, and systemd restarts it — looping forever, with all other channels down each cycle.

Requested fix

1. Ship the main channel-task containment to a published release. Right now no installable tag has it.
2. Handle fatal Slack auth-config errors at start, not just WS errors mid-flight. When auth.test / apps.connections.open returns invalid_auth / account_inactive / token_revoked, mark the Slack channel degraded and do not proceed to app.start() / socket connect; keep the rest of the gateway running (this is the #6867 path, currently not_planned).
3. Exit a distinct non-zero code on a confirmed-fatal Slack auth-config error so supervisors can RestartPreventExitStatus it and stop respawning, instead of a generic status=1 crash-loop.

Operator workaround (until a fixed release ships)

ExecStartPre that runs auth.test against the resolved bot token and exits a sentinel (78) only on a confirmed invalid_auth, paired with RestartPreventExitStatus=78. It warn-and-exits-0 on no-token / network / ratelimit so a transient Slack or secret-manager blip never blocks the other channels.