hermes - 💡(How to fix) Fix BlueBubbles: webhook auto-registration includes 'updated-message', causing every iMessage to be processed twice (with different chat-id variants) [1 pull requests]

Summary

Hermes auto-registers a BlueBubbles webhook subscribed to both new-message AND updated-message. The updated-message event fires for delivery receipts, read state, and attachment finalization — so every inbound iMessage triggers two handle_message invocations. Worse: the two events deliver slightly different chatGuid formats (any;-;+47… and +47…), which create separate session keys, so session-level dedup doesn't catch the duplicate. Net result: every iMessage to the bot gets two replies.

Reproduction

1. Run hermes-gateway with BlueBubbles platform enabled and BB private_api: true.

2. Send any iMessage to the bot.

3. Gateway log shows the same message inbound twice within ~1 second, with different chat IDs:

   inbound message: platform=bluebubbles user=+474****3222 chat=any;-;+474****3222 msg='u there'
   inbound message: platform=bluebubbles user=+474****3222 chat=+474****3222 msg='u there'

4. Two separate agent sessions get spun up. Two replies sent. Often preceded by a (Response formatting failed, plain text:) stray bubble.

Root cause

Two compounding bugs:

1. Webhook hardcodes both events

gateway/platforms/bluebubbles.py:290:

"events": ["new-message", "updated-message"],

_MESSAGE_EVENTS in the same module treats both as inbound message events:

_MESSAGE_EVENTS = {"new-message", "message", "updated-message"}

So receipts/read-state events go straight into handle_message.

2. ChatGuid variants create distinct sessions

The two webhook events deliver different chatGuid formats. Hermes uses the raw chat_id as the session key, so any;-;+47… and +47… produce two distinct sessions. The "is this chat already being processed?" guard in BasePlatformAdapter misses, both passes proceed independently.

Also relevant: BasePlatformAdapter.handle_message has no message-GUID LRU dedup. The MessageEvent.message_id is populated but unused for suppression.

Proposed fixes

Minimum: subscribe only to new-message. updated-message is for receipts / read state / attachment finalization, none of which require a fresh agent turn:

-"events": ["new-message", "updated-message"],
+"events": ["new-message"],

This is the durable fix we landed locally and it resolves the duplicate problem completely.

Better defense-in-depth (orthogonal):

• Add a small recent-message-GUID LRU set in BasePlatformAdapter and short-circuit handle_message if the GUID was seen in the last N seconds. Cheap, handles any future event-source duplication too.
• Normalize chatGuid into the session key — strip the any;-; / iMessage;-; prefix so both formats map to the same session.

If updated-message is intentionally needed for some attachment-finalization edge case, gate processing within the adapter on it: only call handle_message if message.is_from_me == false AND the GUID hasn't been seen in the recent-message LRU.

Happy to submit as a PR.

Environment

• Hermes Agent v0.15.1 (2026.5.29)
• macOS 26.5 Tahoe, Apple Silicon
• BlueBubbles Server 1.9.9 with Private API + Helper