fix(slack): wire up mention_patterns config - #35403
Conversation
Implements `slack.mention_patterns` (regex wake-word triggers in channels), documented in website/docs/user-guide/messaging/slack.md since PR NousResearch#4644 but never wired up. The YAML key was silently accepted by gateway/config.py's generic platform-key loop and then ignored — gateway/platforms/slack.py had zero references to mention_patterns. Mirrors the existing implementations in telegram.py and dingtalk.py: - gateway/platforms/slack.py - _compile_mention_patterns(): reads config.extra["mention_patterns"] and falls back to SLACK_MENTION_PATTERNS env var (JSON / newline / comma-separated, in that order). Invalid regex patterns are skipped with a warning; remaining patterns still compile. Non-list / non-string values log a warning and resolve to []. - _message_matches_mention_patterns(text): True iff any compiled pattern matches. - __init__: cache compiled patterns on the adapter. - Channel gate chain: a regex hit is now a valid trigger alongside reply_to_bot_thread / in_mentioned_thread / has_session. The strict_mention=true escape hatch still bypasses regex triggers, matching Telegram's semantics. - gateway/config.py: bridge slack.mention_patterns from YAML to the SLACK_MENTION_PATTERNS env var, mirroring the existing Telegram / WhatsApp / DingTalk bridges. The generic bridged["mention_patterns"] path already routed the YAML value to config.extra; this extra line keeps Slack symmetric with the other three platforms for deployments that prefer env-var configuration. - tests/gateway/test_slack_mention.py: 12 new cases covering empty default, regex matching, case-insensitivity, single-string form, invalid-regex skipping, non-list rejection, empty-text early return, env-var JSON / multiline fallback, config-extra precedence over env, YAML→env bridging, and env-already-set precedence. Backward compatible: when mention_patterns is absent or empty the channel gate chain is byte-identical to current behavior. The full gateway test suite passes (273 files, 6032 tests, 0 failed).
482b855 to
93a7759
Compare
|
Friendly check-in, happy to address any feedback if this needs changes. Could a maintainer approve the CI workflow when convenient, so the test suite can verify the change end-to-end? I've kept the branch rebased and green locally (full gateway suite + the 12 new mention_patterns cases). Thanks for considering! |
|
This patch is very important to me. The documented behavior and the actual behavior are currently out of sync. I believe this should be addressed as soon as possible to keep the documentation and implementation consistent. |
|
Closing in favor of #50843, which shipped this same fix. Your PR (#35403) was the earliest submission for this issue (May 30) — credit to you for catching it first, @kuk1song. It targeted the old |
What does this PR do?
telegram.py(PR #3870) anddingtalk.py(PR #11564) both implementmention_patterns, which lets a platform adapter treat a configured regex match as a wake trigger (for example, wake on a leading bot name or on any URL) even when the message does not@mentionthe bot.PR #4644 (merged 2026-04-02) documented
slack.mention_patternsinwebsite/docs/user-guide/messaging/slack.md. The Slack adapter, however, never implemented it. The YAML key is silently accepted bygateway/config.py's generic platform-key loop and then ignored, andgateway/platforms/slack.pyhas zero references tomention_patternsonmain. Anyone who follows the Slack docs and setsslack.mention_patternsgets a silent no-op.This PR closes that docs-vs-code drift by giving Slack the same
mention_patternssupport Telegram and DingTalk already ship.Surfaced while wiring a Slack summarizer bot on Hermes: the documented
slack.mention_patternshad no effect, because the adapter never reads the key.Example config.yaml
Behavior
When a channel message does not
@mentionthe bot, it is now accepted as a trigger if it matches any configured regex, alongside the existing reply-to-bot, mentioned-thread, and active-session conditions.strict_mention: truestill requires an explicit@mentionevery turn; regex triggers cannot bypass it (matches Telegram's semantics). DMs are unaffected. Whenmention_patternsis absent or empty, the channel gate chain is byte-identical to current behavior.Related Issue
No dedicated tracking issue; the gap surfaced from PR #4644 documenting
slack.mention_patternswithout the matching adapter implementation landing.A broader prior attempt (#20723 / #20726) bundled this same
mention_patternswiring with unrelated Slack changes (strict-mode behavior tweaks, slash-command aliases,run_agentadjustments) across 6 files. It was withdrawn by its author and not reviewed on merits. This PR isolates only the documentedmention_patternssupport plus tests (3 files, +189 / -2), mirroring the existingtelegram.py/dingtalk.pyimplementations.Type of Change
Changes Made
gateway/platforms/slack.py: add_compile_mention_patterns()and_message_matches_mention_patterns(text)helpers;__init__caches the compiled patterns. The channel gate chain accepts a regex match as a valid trigger alongside the thread and session conditions. Mirrorstelegram.py:4568, 4753, 4824anddingtalk.py:419, 487, 518.gateway/config.py: bridgeslack.mention_patternsfrom YAML toSLACK_MENTION_PATTERNS, keeping Slack symmetric with the existing per-platform bridges (TELEGRAM_MENTION_PATTERNS,WHATSAPP_MENTION_PATTERNS,DINGTALK_MENTION_PATTERNS).tests/gateway/test_slack_mention.py: 12 new cases covering empty default, regex matching, case-insensitivity, single-string form, invalid-regex skipping, non-list rejection, empty-text early return, env-var JSON / multiline fallback, config-extra precedence over env, YAML-to-env bridging, and env-already-set precedence.How to Test
slack.mention_patternsto~/.hermes/config.yaml:@mentioningthe bot:"hello there"→ silently ignored (no pattern match)"hermes what's up"→ bot responds (matches^\s*hermes\b)"check https://example.com"→ bot responds (matcheshttps?://)slack.strict_mention: trueand repeat. All three messages should be ignored unless the bot is explicitly@mentioned(regex triggers do not bypass strict mode, by design).mention_patternsfrom config. Behavior is byte-identical to currentmain.Automated coverage on this branch (rebased onto
5f84c9144):bash scripts/run_tests.sh tests/gateway/passes 273 files / 6032 tests / 0 failed in 44.0s.bash scripts/run_tests.sh tests/gateway/test_slack_mention.pypasses 67/67 (55 pre-existing + 12 new).python scripts/check-windows-footguns.pyclean on the three changed files.ruff checkclean (PLW1514).Checklist
Code
fix(slack): wire up mention_patterns config)bash scripts/run_tests.sh tests/gateway/) and all 6032 tests pass; the change is gateway-only so I scoped local runs there, CI will exercise the fulltests/suitetests/gateway/test_slack_mention.py)uv-managed venvDocumentation & Housekeeping
website/docs/user-guide/messaging/slack.md, themention_patterns:block); no further docs changes needed.cli-config.yaml.examplehas noslack:block today (and no per-platformmention_patternsexamples for Telegram / WhatsApp / DingTalk either), so there is nothing to extend for parity.check-windows-footguns.pypasses.Screenshots / Logs
Expected channel-message behavior with the example config (covered by
tests/gateway/test_slack_mention.py, 67/67 passing):Adjacent in-flight work
PR #29393 (open, currently conflicting) adds the same feature on the Discord side and introduces shared helpers in
gateway/platforms/base.py. If it merges first, I will rebase onto those helpers.