hermes - ✅(Solved) Fix [Bug]: WhatsApp reply-to-bot detection fails — device suffix mismatch in botIds vs quotedParticipant [1 pull requests, 1 comments, 2 participants]

kruzerbot · 2026-05-20T01:35:58Z

[hermes] The message is reply to bot method in gateway/platforms/whatsapp.py consistently returns False for WhatsApp group messages, even when the user explici… The `_message_is_reply_to_bot()` method in `gateway/platforms/whatsapp.py` consistently returns `False` for WhatsApp group messages, even when the user explicitly replies (quotes) a bot message. This makes the reply-to-bot admission shortcut unusable on WhatsApp. **Impact:** Users in groups with `require_mention: true` cannot trigger the bot by replying to its messages — they must always @mention the bot, which is impossible for voice/audio messages since WhatsApp voice notes cannot include text mentions. # PR #29049: fix(whatsapp): match reply-to-bot when botIds carry device suffix - Repository: NousResearch/hermes-agent - Author: luyao618 - State: open | merged: False - Link: https://github.com/NousResearch/hermes-agent/pull/29049 ## Description (problem / solution / changelog) ## Summary Fixes #29023. WhatsApp reply-to-bot detection (`_message_is_reply_to_bot`) consistently returned `False` on multi-device accounts because of a normalized-ID shape mismatch: - Baileys delivers `quotedParticipant` **without** the device suffix: `"5511999999999@s.whatsapp.net"` - `sock.user.{id,lid}` populates `botIds` **with** the device suffix (`:N` → normalized to `@N`): `"5511999999999@10@s.whatsapp.net"` The set-membership check in `gateway/platforms/whatsapp.py` therefore never matched, breaking the reply-to-bot admission shortcut in groups configured with `require_mention: true`. This is especially painful for voice notes, where WhatsApp doesn't support text @mentions at all — there's literally no other way to wake the bot. ## Fix In `_bot_ids_from_message`, when a normalized bot id has three `@`-separated parts (i.e. carries a device suffix), add a suffix-stripped alias alongside the original. Legacy two-part ids are unchanged, so single-device accounts keep their existing behavior. ```python parts = normalized.split("@") if len(parts) > 2: bot_ids.add(f"{parts[0]}@{parts[-1]}") ``` This is exactly the patch the issue author proposed in the Fix section. ## Tests Added two regression tests in `tests/gateway/test_whatsapp_group_gating.py`: - `test_reply_to_bot_matches_device_suffixed_bot_ids` — multi-device botIds (`:10` suffix) + non-suffixed `quotedParticipant` must match and admit the message under `require_mention=true`. - `test_reply_to_bot_legacy_non_multidevice_unchanged` — legacy two-part ids continue to match as before. ``` $ python -m pytest tests/gateway/test_whatsapp_group_gating.py -q 28 passed in 2.52s ``` ## Risk Tiny, surgical, single-function change. The added alias is only emitted when the id has a third `@`-separated component, so it cannot affect legacy callers. No other code paths consume `_bot_ids_from_message` in a way that would break on the extra alias (the other callers use it for `split('@', 1)[0]` bare-id extraction and `in`-checks against `mentionedIds`). ## Changed files - `gateway/platforms/whatsapp.py` (modified, +10/-2) - `tests/gateway/test_whatsapp_group_gating.py` (modified, +35/-0) ## Fix In `gateway/platforms/whatsapp.py`, modify `_bot_ids_from_message()` to also generate ID variants without the device suffix: ```python def _bot_ids_from_message(self, data: Dict[str, Any]) -> set[str]: bot_ids = set() for candidate in data.get("botIds") or []: normalized = self._normalize_whatsapp_id(candidate) if normalized: bot_ids.add(normalized) # Also add without the device suffix (e.g., "5511999999999@10@s.whatsapp.net" -> "5511999999999@s.whatsapp.net") parts = normalized.split("@") if len(parts) > 2: bot_ids.add(f"{parts[0]}@{parts[-1]}") return bot_ids ``` This is safe for both multi-device and non-multi-device: - **Multi-device:** `5511999999999@10@s.whatsapp.net` → adds alias `5511999999999@s.whatsapp.net` - **Legacy:** `5511999999999@s.whatsapp.net` → `len(parts)` is 2 → no alias added, original behavior preserved ## Workaround - Disable `require_mention` globally (not recommended for noisy groups) - Use `free_response_chats` with the specific group JID (allows all messages, not just replies) - Users must @mention the bot (impossible for voice messages) # [Bug]: WhatsApp reply-to-bot detection fails — device suffix mismatch breaks _message_is_reply_to_bot ## Summary The `_message_is_reply_to_bot()` method in `gateway/platforms/whatsapp.py` consistently returns `False` for WhatsApp group messages, even when the user explicitly replies (quotes) a bot message. This makes the reply-to-bot admission shortcut unusable on WhatsApp. **Impact:** Users in groups with `require_mention: true` cannot trigger the bot by replying to its messages — they must always @mention the bot, which is impossible for voice/audio messages since WhatsApp voice notes cannot include text mentions. ## Root Cause The bridge sends `botIds` with the **device suffix** included (`:N` → normalized to `@N`): ```js // bridge.js line ~244-247 const botIds = Array.from

hermes2026-05-20 01:35:58

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

NousResearch/hermes-agent#29023•Fetched 2026-05-20 04:00:34

View on GitHub

Comments

Participants

Timeline

Reactions

Author

kruzerbot

Participants

alt-glitch

kruzerbot

Timeline (top)

labeled ×4cross-referenced ×2commented ×1

The _message_is_reply_to_bot() method in gateway/platforms/whatsapp.py consistently returns False for WhatsApp group messages, even when the user explicitly replies (quotes) a bot message. This makes the reply-to-bot admission shortcut unusable on WhatsApp.

Impact: Users in groups with require_mention: true cannot trigger the bot by replying to its messages — they must always @mention the bot, which is impossible for voice/audio messages since WhatsApp voice notes cannot include text mentions.

Root Cause

The bridge sends botIds with the device suffix included (:N → normalized to @N):

// bridge.js line ~244-247
const botIds = Array.from(new Set([
    normalizeWhatsAppId(sock.user?.id),     // "5511999999999@[email protected]"
    normalizeWhatsAppId(sock.user?.lid),    // "99999999999999@10@lid"
].filter(Boolean)));

However, the quotedParticipant from Baileys contextInfo (extracted at bridge.js line ~321) arrives without the device suffix:

quotedParticipant: "[email protected]"    // no @10
botIds:          {"5511999999999@[email protected]", "99999999999999@10@lid"}

Since _message_is_reply_to_bot() does a strict set membership check:

def _message_is_reply_to_bot(self, data: Dict[str, Any]) -> bool:
    quoted_participant = self._normalize_whatsapp_id(data.get("quotedParticipant"))
    if not quoted_participant:
        return False
    return quoted_participant in self._bot_ids_from_message(data)

The match always fails: "[email protected]" in {"5511999999999@[email protected]", "99999999999999@10@lid"} → False.

Fix Action

Fix

In gateway/platforms/whatsapp.py, modify _bot_ids_from_message() to also generate ID variants without the device suffix:

def _bot_ids_from_message(self, data: Dict[str, Any]) -> set[str]:
    bot_ids = set()
    for candidate in data.get("botIds") or []:
        normalized = self._normalize_whatsapp_id(candidate)
        if normalized:
            bot_ids.add(normalized)
            # Also add without the device suffix (e.g., "5511999999999@[email protected]" -> "[email protected]")
            parts = normalized.split("@")
            if len(parts) > 2:
                bot_ids.add(f"{parts[0]}@{parts[-1]}")
    return bot_ids

This is safe for both multi-device and non-multi-device:

Multi-device: 5511999999999@[email protected] → adds alias [email protected]
Legacy: [email protected] → len(parts) is 2 → no alias added, original behavior preserved

Workaround

Disable require_mention globally (not recommended for noisy groups)
Use free_response_chats with the specific group JID (allows all messages, not just replies)
Users must @mention the bot (impossible for voice messages)

PR fix notes

PR #29049: fix(whatsapp): match reply-to-bot when botIds carry device suffix

Repository: NousResearch/hermes-agent
Author: luyao618
State: open | merged: False
Link: https://github.com/NousResearch/hermes-agent/pull/29049

Description (problem / solution / changelog)

Summary

Fixes #29023. WhatsApp reply-to-bot detection (_message_is_reply_to_bot) consistently returned False on multi-device accounts because of a normalized-ID shape mismatch:

Baileys delivers quotedParticipant without the device suffix: "[email protected]"
sock.user.{id,lid} populates botIds with the device suffix (:N → normalized to @N): "5511999999999@[email protected]"

The set-membership check in gateway/platforms/whatsapp.py therefore never matched, breaking the reply-to-bot admission shortcut in groups configured with require_mention: true. This is especially painful for voice notes, where WhatsApp doesn't support text @mentions at all — there's literally no other way to wake the bot.

Fix

In _bot_ids_from_message, when a normalized bot id has three @-separated parts (i.e. carries a device suffix), add a suffix-stripped alias alongside the original. Legacy two-part ids are unchanged, so single-device accounts keep their existing behavior.

parts = normalized.split("@")
if len(parts) > 2:
    bot_ids.add(f"{parts[0]}@{parts[-1]}")

This is exactly the patch the issue author proposed in the Fix section.

Tests

Added two regression tests in tests/gateway/test_whatsapp_group_gating.py:

test_reply_to_bot_matches_device_suffixed_bot_ids — multi-device botIds (:10 suffix) + non-suffixed quotedParticipant must match and admit the message under require_mention=true.
test_reply_to_bot_legacy_non_multidevice_unchanged — legacy two-part ids continue to match as before.

$ python -m pytest tests/gateway/test_whatsapp_group_gating.py -q
28 passed in 2.52s

Risk

Tiny, surgical, single-function change. The added alias is only emitted when the id has a third @-separated component, so it cannot affect legacy callers. No other code paths consume _bot_ids_from_message in a way that would break on the extra alias (the other callers use it for split('@', 1)[0] bare-id extraction and in-checks against mentionedIds).

Changed files

gateway/platforms/whatsapp.py (modified, +10/-2)
tests/gateway/test_whatsapp_group_gating.py (modified, +35/-0)

Code Example

// bridge.js line ~244-247
const botIds = Array.from(new Set([
    normalizeWhatsAppId(sock.user?.id),     // "5511999999999@[email protected]"
    normalizeWhatsAppId(sock.user?.lid),    // "99999999999999@10@lid"
].filter(Boolean)));

---

quotedParticipant: "[email protected]"    // no @10
botIds:          {"5511999999999@[email protected]", "99999999999999@10@lid"}

---

def _message_is_reply_to_bot(self, data: Dict[str, Any]) -> bool:
    quoted_participant = self._normalize_whatsapp_id(data.get("quotedParticipant"))
    if not quoted_participant:
        return False
    return quoted_participant in self._bot_ids_from_message(data)

---

def _bot_ids_from_message(self, data: Dict[str, Any]) -> set[str]:
    bot_ids = set()
    for candidate in data.get("botIds") or []:
        normalized = self._normalize_whatsapp_id(candidate)
        if normalized:
            bot_ids.add(normalized)
            # Also add without the device suffix (e.g., "5511999999999@[email protected]" -> "[email protected]")
            parts = normalized.split("@")
            if len(parts) > 2:
                bot_ids.add(f"{parts[0]}@{parts[-1]}")
    return bot_ids

RAW_BUFFERClick to expand / collapse

[Bug]: WhatsApp reply-to-bot detection fails — device suffix mismatch breaks _message_is_reply_to_bot

Summary

Root Cause

The bridge sends botIds with the device suffix included (:N → normalized to @N):

// bridge.js line ~244-247
const botIds = Array.from(new Set([
    normalizeWhatsAppId(sock.user?.id),     // "5511999999999@[email protected]"
    normalizeWhatsAppId(sock.user?.lid),    // "99999999999999@10@lid"
].filter(Boolean)));

However, the quotedParticipant from Baileys contextInfo (extracted at bridge.js line ~321) arrives without the device suffix:

quotedParticipant: "[email protected]"    // no @10
botIds:          {"5511999999999@[email protected]", "99999999999999@10@lid"}

Since _message_is_reply_to_bot() does a strict set membership check:

def _message_is_reply_to_bot(self, data: Dict[str, Any]) -> bool:
    quoted_participant = self._normalize_whatsapp_id(data.get("quotedParticipant"))
    if not quoted_participant:
        return False
    return quoted_participant in self._bot_ids_from_message(data)

The match always fails: "[email protected]" in {"5511999999999@[email protected]", "99999999999999@10@lid"} → False.

Environment

Platform: WhatsApp (Baileys bridge, multi-device)
Hermes version: Observed May 2026
Affected: All WhatsApp groups with require_mention: true

Reproduction

Configure whatsapp.require_mention: true in config.yaml
Join a WhatsApp group with the bot
Have the bot send any message in the group
Reply (quote) the bots message with a text reply
Expected: Bot processes the reply without needing @mention
Actual: Bot silently ignores the message — _message_is_reply_to_bot returns False

Fix

In gateway/platforms/whatsapp.py, modify _bot_ids_from_message() to also generate ID variants without the device suffix:

def _bot_ids_from_message(self, data: Dict[str, Any]) -> set[str]:
    bot_ids = set()
    for candidate in data.get("botIds") or []:
        normalized = self._normalize_whatsapp_id(candidate)
        if normalized:
            bot_ids.add(normalized)
            # Also add without the device suffix (e.g., "5511999999999@[email protected]" -> "[email protected]")
            parts = normalized.split("@")
            if len(parts) > 2:
                bot_ids.add(f"{parts[0]}@{parts[-1]}")
    return bot_ids

This is safe for both multi-device and non-multi-device:

Multi-device: 5511999999999@[email protected] → adds alias [email protected]
Legacy: [email protected] → len(parts) is 2 → no alias added, original behavior preserved

Workaround

Disable require_mention globally (not recommended for noisy groups)
Use free_response_chats with the specific group JID (allows all messages, not just replies)
Users must @mention the bot (impossible for voice messages)

Type of Change

🐛 Bug fix

Files Changed

gateway/platforms/whatsapp.py — _bot_ids_from_message() — 3 lines added

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

#tensor shape #autograd error #model save/load #optimization #mixed precision

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Data

Security

Network

Code

UI/UX

Text

System

Multimedia

Protocol

API

Engineering

hermes - ✅(Solved) Fix [Bug]: WhatsApp reply-to-bot detection fails — device suffix mismatch in botIds vs quotedParticipant [1 pull requests, 1 comments, 2 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Fix Action

Fix

Workaround

PR fix notes

PR #29049: fix(whatsapp): match reply-to-bot when botIds carry device suffix

Description (problem / solution / changelog)

Summary

Fix

Tests

Risk

Changed files

Code Example

[Bug]: WhatsApp reply-to-bot detection fails — device suffix mismatch breaks _message_is_reply_to_bot

Summary

Root Cause

Environment

Reproduction

Fix

Workaround

Type of Change

Files Changed

Still need to ship something?

TRENDING

hermes - ✅(Solved) Fix [Bug]: WhatsApp reply-to-bot detection fails — device suffix mismatch in botIds vs quotedParticipant [1 pull requests, 1 comments, 2 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Fix Action

Fix

Workaround

PR fix notes

PR #29049: fix(whatsapp): match reply-to-bot when botIds carry device suffix

Description (problem / solution / changelog)

Summary

Fix

Tests

Risk

Changed files

Code Example

[Bug]: WhatsApp reply-to-bot detection fails — device suffix mismatch breaks _message_is_reply_to_bot

Summary

Root Cause

Environment

Reproduction

Fix

Workaround

Type of Change

Files Changed

Still need to ship something?

RELATED_DISCOVERY

TRENDING