fix(slack): decode the bot self mention in incoming message text - #891
Merged
Conversation
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Signed-off-by: dancer <josh@afterima.ge>
dancer
approved these changes
Sep 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When a Slack message mentions the bot, the adapter resolves every mention in the text to a display name — except the bot's own.
<@U_BOT>stays inmessage.textas raw user-ID markup while other mentions become@<DisplayName>.Downstream consumers therefore see inconsistent text. For LLM-based consumers this is actively harmful: small models classify differently depending on whether the mention arrived as self-describing
@<DisplayName>text or as cryptic<@U_BOT>markup, and there is no way for a consumer to tell a real mention from a lookalike string without re-implementing Slack's mrkdwn rules.The reason the bot's own mention was left raw is detection coupling:
Chat.detectMentionmatched@botUserId/<@botUserId>in the text, so resolving the markup would have hidden the mention from detection.Changes
resolveInlineMentionsnow decodes the bot's own mention like any other:<@U_BOT>resolves to@<DisplayName>(via the sameusers.infolookup and cache as all other mentions).parseSlackMessagetests the raw event text for the bot's mention (labeled, unlabeled, and bare@IDforms) and setsisMentionon the parsed message.Chat.detectMentionremains as the fallback for username-style mentions on the rendered text.skipSelfMentionoption is removed; the history/thread fetch paths that passedskipSelfMention: falsenow behave identically to live events, which also fixes an inconsistency where edited messages (parseSlackMessageSync) never resolved mentions at all.Behavior change
message.textfor a message that mentions the bot changes from<@U_BOT> helloto@Vercel Bot hello(the bot's resolved display name). Mention detection is preserved:isMentionis set from the raw event text, and the labeled form is matched by the new detection patterns. Apps matching the raw<@U_BOT>markup inmessage.textshould match the resolved display name or readmessage.rawinstead.Relation to #355
#355 intentionally introduced the self-mention skip: in multi-workspace installs, the request-scoped bot ID was being resolved before mention detection ran, which broke
onNewMentionfor those workspaces. This PR preserves that guarantee without the markup coupling — the multi-workspace replay test from that scenario is updated and still asserts that a plainmessageevent containing the bot's mention setsisMention: trueand routes toonNewMention. Detection additionally covers the labeled form (<@U_BOT|Name>) that resolution now produces.