Slack: handle message.channels and message.groups events by liuxiaopai-ai · Pull Request #31701 · openclaw/openclaw

liuxiaopai-ai · 2026-03-02T13:07:35Z

Summary

register explicit Slack monitor handlers for message.channels and message.groups
route both typed handlers through the existing message event pipeline
add regression coverage to verify typed message handlers are registered and forwarded
update changelog with the fix entry for [Bug]: Slack connector needs message.channels handler for channel visibility #31674

Testing

pnpm test src/slack/monitor/events/messages.test.ts
pnpm exec oxlint src/slack/monitor/events/messages.ts src/slack/monitor/events/messages.test.ts

greptile-apps · 2026-03-02T13:13:03Z

Greptile Summary

This PR addresses an issue where Slack channel and group messages were not being processed when Slack dispatched them using typed event names (message.channels and message.groups) instead of the generic message event. The fix cleanly refactors the existing message handler logic into a shared handleIncomingMessageEvent function and registers explicit handlers for both typed event types, ensuring all three event delivery styles route through the same processing pipeline.

Key changes:

Extracted message handling logic into handleIncomingMessageEvent to avoid code duplication
Registered explicit handlers for message.channels and message.groups events alongside the existing message handler
Added regression test coverage verifying both typed handlers are registered and forward events correctly
Updated CHANGELOG with fix entry for [Bug]: Slack connector needs message.channels handler for channel visibility #31674

Technical notes:

The typed handlers use SlackEventMiddlewareArgs without a type parameter since message.channels and message.groups aren't predefined event types in the Bolt TypeScript definitions
All message subtypes (message_changed, message_deleted, thread_broadcast) are handled consistently across all three event types through the shared function
The refactoring maintains backward compatibility while adding support for Slack's alternate event dispatch mechanism

Confidence Score: 5/5

This PR is safe to merge with minimal risk
The changes are straightforward and additive - registering additional event handlers without modifying existing behavior. The refactoring cleanly extracts shared logic to avoid duplication, test coverage validates the new handlers work correctly, and the implementation properly routes all event types through the same well-tested processing pipeline. No logical errors, security issues, or edge cases were found.
No files require special attention

_{Last reviewed commit: 4d5ebc2}

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4d5ebc225a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-03-02T13:13:06Z

src/slack/monitor/events/messages.ts

+  ctx.app.event("message.channels", async ({ event, body }: SlackEventMiddlewareArgs) => {
+    await handleIncomingMessageEvent({ event, body });
+  });
+  ctx.app.event("message.groups", async ({ event, body }: SlackEventMiddlewareArgs) => {


Register typed DM message events too

This patch only adds listeners for message.channels and message.groups, but the same typed-dispatch mode also uses message.im and message.mpim for DM/MPIM subscriptions (which are still listed in our Slack setup docs). In workspaces where Bolt routes by these typed names, DM and group-DM messages will continue to bypass handleIncomingMessageEvent, so inbound Slack conversations can still be dropped even after this fix.

Useful? React with 👍 / 👎.

@liuxiaopai-ai

…(thanks @liuxiaopai-ai)

steipete · 2026-03-02T13:33:23Z

Landed via temp rebase onto main.

Gate: pnpm lint && pnpm build && pnpm test (test suite currently has 2 unrelated failures in src/process/exec.test.ts)
Land commit: 5efb970
Merge commit: 0630650

Thanks @liuxiaopai-ai!

…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

…h Bolt 4.6 (#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 #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 #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 #31674 (original issue was not caused by missing handlers) * fix: document Slack Bolt 4.6 startup handler fix (#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>

@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>

liuxiaopai-ai added 2 commits March 2, 2026 21:06

Slack: register typed channel/group message event handlers

0227f65

Slack: format typed message event handler

4d5ebc2

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

chatgpt-codex-connector bot reviewed Mar 2, 2026

View reviewed changes

steipete added a commit that referenced this pull request Mar 2, 2026

fix(slack): typed message handler typing + subtype coverage (#31701) …

5efb970

…(thanks @liuxiaopai-ai)

steipete merged commit 0630650 into openclaw:main Mar 2, 2026
23 of 25 checks passed

This was referenced Mar 2, 2026

fix(slack): handle channel-scoped message events [AI-assisted] #31681

Closed

Slack: add message.channels and message.groups handlers for channel visibility(#31674) #31700

Closed

fix(slack): add actionable no-mention hint for channel skips #31702

Closed

steipete added a commit that referenced this pull request Mar 2, 2026

fix(slack): correct typed message event overloads (#31701)

3bc36ce

steipete added a commit to liuxiaopai-ai/openclaw that referenced this pull request Mar 2, 2026

fix(slack): correct typed message event overloads (openclaw#31701)

c5c9e5f

eveiljuice pushed a commit to eveiljuice/openclaw-II that referenced this pull request Mar 2, 2026

fix(slack): correct typed message event overloads (openclaw#31701)

d86c1a6

vabole mentioned this pull request Mar 2, 2026

ops: decision needed for upstream sync (4 disputed files) vabole/openclaw#7

Merged

4 tasks

obviyus pushed a commit that referenced this pull request Mar 2, 2026

fix(slack): correct typed message event overloads (#31701)

884b12a

Linux2010 pushed a commit to Linux2010/openclaw that referenced this pull request Mar 2, 2026

fix(slack): correct typed message event overloads (openclaw#31701)

0838e8d

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

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

Open

mahopan mentioned this pull request Mar 2, 2026

[Bug]: Slack provider crashes on startup — Bolt 4.6 rejects message.channels/message.groups event registration #32032

Closed

mahopan mentioned this pull request Mar 2, 2026

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

Merged

2 tasks

execute008 pushed a commit to execute008/openclaw that referenced this pull request Mar 2, 2026

fix(slack): correct typed message event overloads (openclaw#31701)

a323c71

dawi369 pushed a commit to dawi369/davis that referenced this pull request Mar 3, 2026

fix(slack): correct typed message event overloads (openclaw#31701)

9b2e63f

OWALabuy pushed a commit to kcinzgg/openclaw that referenced this pull request Mar 4, 2026

fix(slack): correct typed message event overloads (openclaw#31701)

ebc2a60

zooqueen pushed a commit to hanzoai/bot that referenced this pull request Mar 6, 2026

fix(slack): correct typed message event overloads (openclaw#31701)

0fc7426

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Slack: handle message.channels and message.groups events#31701

Slack: handle message.channels and message.groups events#31701
steipete merged 2 commits intoopenclaw:mainfrom
liuxiaopai-ai:fix/slack-typed-message-events-31674

liuxiaopai-ai commented Mar 2, 2026

Uh oh!

greptile-apps bot commented Mar 2, 2026

Uh oh!

chatgpt-codex-connector bot left a comment

Uh oh!

chatgpt-codex-connector bot 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

liuxiaopai-ai commented Mar 2, 2026

Summary

Testing

Uh oh!

greptile-apps bot commented Mar 2, 2026

Greptile Summary

Confidence Score: 5/5

Uh oh!

chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector bot Mar 2, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

steipete commented Mar 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants