fix(slack): remove message.channels/message.groups handlers that crash Bolt 4.6 by mahopan · Pull Request #32033 · openclaw/openclaw

mahopan · 2026-03-02T18:22:03Z

Summary

Remove message.channels and message.groups event handler registrations that cause all Slack providers to crash on startup with @slack/bolt@4.6.0.

Root Cause

PR #31701 added ctx.app.event("message.channels", ...) and ctx.app.event("message.groups", ...) handlers based on the assumption that Slack dispatches typed event names to Bolt. However:

Bolt 4.6 explicitly rejects app.event() calls with names starting with "message.", throwing AppInitializationError
Slack never dispatches events with type: "message.channels" — these are subscription labels in the Slack App manifest, not event types
The actual payload always arrives with type: "message" and uses the channel_type field ("channel" | "group" | "im" | "mpim") to distinguish the source
The existing app.event("message") handler already receives all message events regardless of channel type

Changes

messages.ts: Remove the two broken app.event("message.channels/groups") registrations; add explanatory comment about subscription labels vs event types. Preserves the handleIncomingMessageEvent function extraction from Slack: handle message.channels and message.groups events #31701.
messages.test.ts: Replace message.channels/message.groups handler tests with a test verifying channel and group messages are handled via the unified "message" handler using channel_type.

Verification

pnpm build ✅
pnpm check ✅
pnpm test src/slack/monitor/events/messages.test.ts — 7/7 passed ✅
Gateway restart: all 4 Slack accounts connect successfully via Socket Mode ✅

Change Type

Bug fix

Scope

Integrations

Linked Issues

Fixes [Bug]: Slack provider crashes on startup — Bolt 4.6 rejects message.channels/message.groups event registration #32032
Reverts the breaking change from Slack: handle message.channels and message.groups events #31701 / fix(slack): type message.channels/group handlers #31758
Re: [Bug]: Slack connector needs message.channels handler for channel visibility #31674 (original issue was not caused by missing event handlers)

Security Impact

New permissions/capabilities? No
Secrets/tokens handling changed? No
New/changed network calls? No
Command/tool execution surface changed? No
Data access scope changed? No

Compatibility

Backward compatible? Yes
Config/env changes? No
Migration needed? No

greptile-apps · 2026-03-02T18:26:43Z

Greptile Summary

Removes two invalid Slack event handlers (message.channels and message.groups) that cause crashes with @slack/bolt@4.6.0. These were subscription labels mistakenly registered as event types, but Slack always sends events as type: "message" with a channel_type field to distinguish the source. The unified message handler already receives all message events regardless of channel type.

Removed broken app.event("message.channels") and app.event("message.groups") handler registrations that cause AppInitializationError in Bolt 4.6+
Added explanatory comment clarifying the distinction between subscription labels and actual event types
Updated tests to verify channel and group messages are correctly handled via the unified message handler
Preserved the handleIncomingMessageEvent function extraction and all existing message handling logic
The Slack App manifest correctly keeps message.channels and message.groups as subscription labels in src/channels/plugins/onboarding/slack.ts (lines 80-81), which is the proper usage

Confidence Score: 5/5

This PR is safe to merge - it removes code that explicitly crashes the application and has been verified to work in production
The fix is minimal, well-tested, and addresses a critical bug. It removes handlers that cause startup crashes while preserving all functionality through the existing unified message handler. The PR author has verified successful Gateway restart with all 4 Slack accounts.
No files require special attention

_{Last reviewed commit: 8484b6b}

…h Bolt 4.6 Bolt 4.6 rejects app.event() calls with event names starting with "message." (e.g. "message.channels", "message.groups"), throwing AppInitializationError on startup. These handlers were added in openclaw#31701 based on the incorrect assumption that Slack dispatches typed event names to Bolt. In reality, Slack always delivers events with type:"message" regardless of the Event Subscription name; the channel_type field distinguishes the source. The generic app.event("message") handler already receives all channel, group, IM, and MPIM messages. The additional typed handlers were unreachable even if Bolt allowed them, since no event payload ever carries type:"message.channels". This preserves the handleIncomingMessageEvent refactor from openclaw#31701 (extracting the handler into a named function) while removing only the broken registrations. Fixes the Slack provider crash loop affecting all accounts on @slack/bolt >= 4.6.0. Closes openclaw#31674 (original issue was not caused by missing handlers)

@mahopan

…anks @mahopan)

steipete · 2026-03-02T18:32:45Z

Landed via temp rebase onto main.

Gate: bunx vitest run src/slack/monitor/events/messages.test.ts
Land commit: 9e1f70e
Merge commit: d21cf44

Thanks @mahopan!

@mahopan

…h Bolt 4.6 (openclaw#32033) * fix(slack): remove message.channels/message.groups handlers that crash Bolt 4.6 Bolt 4.6 rejects app.event() calls with event names starting with "message." (e.g. "message.channels", "message.groups"), throwing AppInitializationError on startup. These handlers were added in openclaw#31701 based on the incorrect assumption that Slack dispatches typed event names to Bolt. In reality, Slack always delivers events with type:"message" regardless of the Event Subscription name; the channel_type field distinguishes the source. The generic app.event("message") handler already receives all channel, group, IM, and MPIM messages. The additional typed handlers were unreachable even if Bolt allowed them, since no event payload ever carries type:"message.channels". This preserves the handleIncomingMessageEvent refactor from openclaw#31701 (extracting the handler into a named function) while removing only the broken registrations. Fixes the Slack provider crash loop affecting all accounts on @slack/bolt >= 4.6.0. Closes openclaw#31674 (original issue was not caused by missing handlers) * fix: document Slack Bolt 4.6 startup handler fix (openclaw#32033) (thanks @mahopan) --------- Co-authored-by: Peter Steinberger <steipete@gmail.com>

@mahopan

…h Bolt 4.6 (openclaw#32033) * fix(slack): remove message.channels/message.groups handlers that crash Bolt 4.6 Bolt 4.6 rejects app.event() calls with event names starting with "message." (e.g. "message.channels", "message.groups"), throwing AppInitializationError on startup. These handlers were added in openclaw#31701 based on the incorrect assumption that Slack dispatches typed event names to Bolt. In reality, Slack always delivers events with type:"message" regardless of the Event Subscription name; the channel_type field distinguishes the source. The generic app.event("message") handler already receives all channel, group, IM, and MPIM messages. The additional typed handlers were unreachable even if Bolt allowed them, since no event payload ever carries type:"message.channels". This preserves the handleIncomingMessageEvent refactor from openclaw#31701 (extracting the handler into a named function) while removing only the broken registrations. Fixes the Slack provider crash loop affecting all accounts on @slack/bolt >= 4.6.0. Closes openclaw#31674 (original issue was not caused by missing handlers) * fix: document Slack Bolt 4.6 startup handler fix (openclaw#32033) (thanks @mahopan) --------- Co-authored-by: Peter Steinberger <steipete@gmail.com>

@mahopan

…h Bolt 4.6 (openclaw#32033) * fix(slack): remove message.channels/message.groups handlers that crash Bolt 4.6 Bolt 4.6 rejects app.event() calls with event names starting with "message." (e.g. "message.channels", "message.groups"), throwing AppInitializationError on startup. These handlers were added in openclaw#31701 based on the incorrect assumption that Slack dispatches typed event names to Bolt. In reality, Slack always delivers events with type:"message" regardless of the Event Subscription name; the channel_type field distinguishes the source. The generic app.event("message") handler already receives all channel, group, IM, and MPIM messages. The additional typed handlers were unreachable even if Bolt allowed them, since no event payload ever carries type:"message.channels". This preserves the handleIncomingMessageEvent refactor from openclaw#31701 (extracting the handler into a named function) while removing only the broken registrations. Fixes the Slack provider crash loop affecting all accounts on @slack/bolt >= 4.6.0. Closes openclaw#31674 (original issue was not caused by missing handlers) * fix: document Slack Bolt 4.6 startup handler fix (openclaw#32033) (thanks @mahopan) --------- Co-authored-by: Peter Steinberger <steipete@gmail.com>

@mahopan

…h Bolt 4.6 (openclaw#32033) * fix(slack): remove message.channels/message.groups handlers that crash Bolt 4.6 Bolt 4.6 rejects app.event() calls with event names starting with "message." (e.g. "message.channels", "message.groups"), throwing AppInitializationError on startup. These handlers were added in openclaw#31701 based on the incorrect assumption that Slack dispatches typed event names to Bolt. In reality, Slack always delivers events with type:"message" regardless of the Event Subscription name; the channel_type field distinguishes the source. The generic app.event("message") handler already receives all channel, group, IM, and MPIM messages. The additional typed handlers were unreachable even if Bolt allowed them, since no event payload ever carries type:"message.channels". This preserves the handleIncomingMessageEvent refactor from openclaw#31701 (extracting the handler into a named function) while removing only the broken registrations. Fixes the Slack provider crash loop affecting all accounts on @slack/bolt >= 4.6.0. Closes openclaw#31674 (original issue was not caused by missing handlers) * fix: document Slack Bolt 4.6 startup handler fix (openclaw#32033) (thanks @mahopan) --------- Co-authored-by: Peter Steinberger <steipete@gmail.com>

openclaw-barnacle bot added channel: slack Channel integration: slack size: XS labels Mar 2, 2026

mahopan force-pushed the fix/slack-message-channels-crash branch from 8484b6b to 9bf5e0a Compare March 2, 2026 18:27

mahopan and others added 2 commits March 2, 2026 18:31

fix: document Slack Bolt 4.6 startup handler fix (openclaw#32033) (th…

9e1f70e

…anks @mahopan)

steipete force-pushed the fix/slack-message-channels-crash branch from 9bf5e0a to 9e1f70e Compare March 2, 2026 18:32

steipete merged commit d21cf44 into openclaw:main Mar 2, 2026
6 checks passed

github-actions bot mentioned this pull request Mar 2, 2026

📡 Upstream Digest — 2026-03-02 18:35 UTC curtismercier/openclaw-mods#165

Open

This was referenced Mar 2, 2026

fix(slack): register message.channels and message.groups handlers #31725

Closed

fix(slack): avoid invalid Bolt typed message handlers #32037

Closed

sourman mentioned this pull request Mar 2, 2026

fix(slack): remove message.channels/groups event handlers incompatible with Bolt v4.6.0 #32070

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(slack): remove message.channels/message.groups handlers that crash Bolt 4.6#32033

fix(slack): remove message.channels/message.groups handlers that crash Bolt 4.6#32033
steipete merged 2 commits intoopenclaw:mainfrom
mahopan:fix/slack-message-channels-crash

mahopan commented Mar 2, 2026

Uh oh!

greptile-apps bot commented Mar 2, 2026

Uh oh!

Uh oh!

steipete commented Mar 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

mahopan commented Mar 2, 2026

Summary

Root Cause

Changes

Verification

Change Type

Scope

Linked Issues

Security Impact

Compatibility

Uh oh!

greptile-apps bot commented Mar 2, 2026

Greptile Summary

Confidence Score: 5/5

Uh oh!

Uh oh!

steipete commented Mar 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants