Fix Slack peer bot-user routing loops

[OfficialDelta]

Summary

Fix Slack peer-agent routing so Slack bot-user identities are handled by the allow_bots policy even when Slack delivers the event as a normal message without bot_id, bot_profile, or subtype=bot_message.

This prevents peer-agent status/error/control posts from waking another agent through stale thread/session context unless the current message explicitly mentions that target bot.

Root cause

In a live peer-agent Slack incident, operational warning messages from one agent were delivered as ordinary Slack message events with a bot user id but no bot-message event shape. The adapter only treated messages as bot-originated when fields like bot_id, bot_profile, or subtype=bot_message were present.

With allow_bots: mentions, those bot-user messages could therefore be treated like normal users. In a thread where the parent already mentioned a target agent, active session/thread routing could accept warning/status posts that did not freshly mention the target, causing bot-to-bot wakeups and poisoned session turns.

Fix

• Resolve and cache Slack user bot identity through the existing users.info path.
• Apply allow_bots behavior to bot-user senders, not only Slack events with explicit bot-message fields.
• For allow_bots: mentions, require a fresh current-message mention for bot-user senders.
• Preserve legitimate explicit peer-bot mentions.
• Harden mocked/malformed users_info responses in tests so they are treated conservatively as non-bot.
• Fix Slack mention/config-bridge test hygiene so SLACK_* env mutations do not leak into later routing tests.

Verification

Run on a clean branch based on current origin/main:

• pytest tests/gateway/test_slack.py::TestMessageRouting tests/gateway/test_slack_mention.py -q
  • 70 passed in 4.14s
• pytest tests/gateway/test_slack.py -q
  • 211 passed, 4 warnings in 9.86s

The warnings are pre-existing AsyncMock/thread fixture warnings in unrelated Slack tests; the new routing regressions pass.

Operational note

A separate live deployment normalized affected peer-agent profiles to direct-mention-only Slack behavior:

• slack.require_mention: true
• slack.strict_mention: true
• slack.allow_bots: mentions
• slack.allowed_channels: ''

This PR addresses the source-level routing bug that made allow_bots: mentions insufficient for bot-user-shaped Slack events.

[OfficialDelta]

Follow-up repo issues created from the same incident:

• Codex hidden-reasoning-only incomplete turns can poison gateway sessions #51628 — Codex hidden-reasoning-only incomplete turns can poison gateway sessions
• Gateway state can be stale or misleading during restart/startup #51629 — Gateway state can be stale or misleading during restart/startup
• Add repeatable Slack peer-agent routing smoke test #51630 — Add repeatable Slack peer-agent routing smoke test

This PR addresses the source-level Slack bot-user routing bug; the follow-ups cover the Codex/gateway observability/smoke-test work that should not be bundled into this fix.

[tonydwb]

Code Review Summary

Verdict: Approved

Solid fix for Slack peer bot-user routing loops. The core issue: some Slack bot posts arrive as ordinary-looking message events with a bot user id but without bot_id/subtype=bot_message, causing agent-agent loops.

Key improvements:

• New _user_is_bot_cache dict and _resolve_user_is_bot() method with proper caching
• _event_declares_bot_sender() helper consolidates bot detection logic
• _slack_allow_bots() extracted as a clean config accessor
• Applied allow_bots policy to resolved bot users after the initial event-level check
• Good test coverage for both ignore (no mention) and route (explicit mention) cases
• Also cleans up environment variable leaks in test_slack_mention.py

No security concerns. The fix correctly prevents bot-to-bot loops while preserving legitimate peer-agent @mention routing.

---

Reviewed by Hermes Agent

[teknium1]

Thanks for isolating the peer-bot routing case; current main still has the reported gap. plugins/platforms/slack/adapter.py:2600-2615 only applies allow_bots to event-declared bots, while the later routing path permits a reply in a previously mentioned thread (plugins/platforms/slack/adapter.py:2826-2868).

Problems

• Blocking: the new isinstance(result, dict) guards at plugins/platforms/slack/adapter.py:1884 and in _resolve_user_is_bot() reject slack-sdk's production AsyncSlackResponse. The pinned slack-sdk==3.40.1 response is non-dict but implements .get(), which is also the interface current main uses at plugins/platforms/slack/adapter.py:2091-2102. Live bot users would therefore be cached as non-bots, and _resolve_user_name() would regress to user IDs.
• The added tests use plain dict mocks, so they do not cover that production response shape.

Suggested changes

• Accept the response's existing .get() interface rather than requiring dict, and add a non-dict .get() fixture to both new routing cases.

This is an automated hermes-sweeper review.

[teknium1]

AsyncWebClient.users_info() returns slack-sdk's AsyncSlackResponse, which provides .get() but is not a dict. This branch will cache every live response as non-bot (and the tests use only dict mocks), so the peer-bot routing fix never activates in production. Accept mapping-like .get() responses and add a non-dict response fixture.

[teknium1]

Merged via #69483 — your commit was cherry-picked/reapplied onto current main with your authorship preserved in git history: your peer bot-user routing fix is the base of the bot-loop sub-cluster — reworked onto workspace-scoped cache keys with your authorship, fixes #50973.

Thanks for the contribution!