Bug Description

In a Google Chat space (not a DM), when the bot is @-mentioned in two different threads within roughly the same second, the bot's outbound reply for one of those mentions occasionally posts into the other thread. The user sees their question answered, but in the wrong place — and any follow-up in the originating thread is broken because the reply never landed there.

It's intermittent (race-conditioned), so it doesn't reproduce on every attempt, but it's very repeatable under bursty traffic in a busy space.

Steps to Reproduce

1. Add the bot to a Google Chat space that already has at least two active threads (Thread A and Thread B).
2. From Thread A, @bot ask a question that takes a couple of seconds to answer (e.g. anything that triggers a tool call, a model call with a non-trivial prompt, or image generation — anything where the inbound→outbound latency is >~500 ms).
3. Within ~1 second, from Thread B, @bot send a different question.
4. Repeat a few times. On some attempts, the reply intended for Thread A is posted into Thread B (or vice-versa). Occasionally a reply lands at the space top-level instead of in either thread.

Expected Behavior

Each outbound reply lands in the same thread as the inbound mention that triggered it, regardless of how closely other mentions arrive in the same space.

Actual Behavior

Replies get crossed between threads under concurrent inbound mentions in the same space. Sometimes a reply lands at top-level instead of in any thread.

Likely cause (from a read of plugins/platforms/google_chat/adapter.py)

The adapter caches the most recent inbound thread per space in a single-slot dict:

# adapter.py ~L507
# Last-seen inbound thread name per chat_id (space).
self._last_inbound_thread: Dict[str, str] = {}

_resolve_thread_id (≈L2086) falls back to that cache when metadata['thread_id'] isn't carried through on the outbound side:

if chat_id:
    cached = self._last_inbound_thread.get(chat_id)
    if cached:
        return cached

Because the cache is keyed by chat_id only (not by the originating message / session / thread), two near-simultaneous inbound messages in the same space race: the second inbound overwrites _last_inbound_thread[chat_id] before the slower outbound for the first inbound resolves its thread → the slower reply is routed into the second message's thread.

_ThreadCountStore is keyed by (chat_id, thread_name), which is fine in isolation, but its "main-flow vs side-thread" heuristic (the prev_count == 0 branch, ~L324) treats any thread we haven't seen yet as "Google Chat auto-created this thread for the user — reply at top-level". Under the burst, the heuristic can fire for whichever thread loses the race and demote a real side-thread reply to top-level. That matches the occasional "reply lands at space top-level" symptom above.

Suggested fix

Outbound thread routing should be derived from per-message state captured at inbound time, not from mutable, single-slot adapter state.

Concretely:

• Carry the inbound thread.name on the message context object itself (e.g. on the gateway's session source / event metadata) all the way through to the send path, and have _resolve_thread_id read it from there.
• Drop, or at minimum scope, _last_inbound_thread. If a fallback is still needed for DMs (where thread_id is intentionally stripped to keep session_key stable), key it by (chat_id, session_id) or — better — by the originating message id, not by chat_id alone.
• Same for the _ThreadCountStore side-thread heuristic: the "first time we see this thread" branch is a per-thread historical fact and shouldn't be allowed to flip based on inter-message timing in the same space.

Affected Component

• Gateway (Google Chat platform adapter — plugins/platforms/google_chat/adapter.py)

Messaging Platform

• Google Chat (not in the bug-report dropdown — flagging here)

Environment

• I will attach hermes debug share links here when I can reliably reproduce on the latest version. Filing now so the analysis isn't lost; happy to follow up with logs.