fix(slack): read mentions from message content

[privatenumber]

Summary

• Code samples that contain the bot's id no longer start a conversation
• Real mentions keep working, including beside a code sample
• Depends on #946, which lets the adapter's non-mention decision stick

Problem

Chat SDK routes a message to onNewMention when the bot is mentioned, and the Slack adapter decided that from the raw text: it scanned for the bot's id and marked every app_mention event as a mention.

Slack models those two cases differently. A user mention "renders as a mention of a user", while a text element with style.code displays literal code. Both can carry the same id characters:

{ "type": "text", "text": "<@UBOT123>", "style": { "code": true } }

{ "type": "user", "user_id": "UBOT123" }

Only the second is a mention. Because the adapter also searched the text, a message that only documents the bot was treated as an invocation:

1. A user posts a code sample that contains the bot's id.
2. Slack delivers the event as app_mention.
3. The adapter set isMention, and the mention handler ran.

Changes

The adapter now classifies the content the way Slack renders it, instead of scanning every string for the bot's id.

• A user element for the bot outside code is a mention.
• A <@U…> token in a text object explicitly typed mrkdwn is a mention.
• Inline code (style.code) and preformatted elements are not.
• A rich-text text element, a link label, and a raw_text table cell are display text. A token there stays literal, so it is not a mention.

When a message carries blocks, those blocks model its body and the flattened text field is not consulted, because it loses the code/literal distinction. Attachment blocks are authoritative for their attachment, so an attachment's legacy fallback cannot add mention evidence. Blocks and mrkdwn content are both traversed, so a section block mention is still found.

The unconditional app_mention override is gone. A fully inspected message with no mention reports isMention: false, even when the bot's display name appears as plain text, which #946 preserves. If the adapter cannot identify the bot (botUserId unresolved), an app_mention event is still trusted and other messages stay undetermined.

The routing test in packages/adapter-slack/src/index.test.ts sends a signed webhook through the real adapter and a real Chat instance. Against the pre-fix adapter it fails because the mention handler runs; with the fix it passes. Seven cases were confirmed to fail before the element-type fix, covering raw_text cells, rich-text text elements, link labels, plain_text blocks, and attachment fallbacks.

The Slack integration suite also delivered events as text: "@botname ...". Slack mentions are <@U…> tokens, so those fixtures were corrected to the documented syntax; the operations those tests own (subscriptions, edits, reactions, uploads) are unchanged.

Changed files:

• packages/adapter-slack/src/index.ts: element-typed mention classification across rich text, tables, and attachments
• packages/adapter-slack/src/index.test.ts: adapter-level classification and webhook-to-handler routing
• packages/integration-tests/src/slack.test.ts: mention fixtures corrected to <@U…> syntax

Related PRs

• Depends on #946: without it, Chat re-detects the mention from the flattened text and the false positive returns

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
chat	Ready	Preview, v0	Sep 17, 2026 9:34am UTC
chat-sdk-nextjs-chat	Ready	Preview, v0	Sep 17, 2026 9:34am UTC