fix(gateway): key email thread context by root Message-ID instead of sender address

[buzz-code]

What changed and why

_thread_context was keyed by sender_addr, so all emails from the same
person shared a single thread entry. If Alice sent two unrelated emails,
the second would clobber the first's context — replies would use the wrong
subject, In-Reply-To, and References headers, breaking email threading
in most clients.

Introduce _extract_thread_id() to derive the canonical thread root per
RFC 2822:

1. First Message-ID in the References chain
2. In-Reply-To if no References
3. The email's own Message-ID for new threads
4. A local UUID fallback for malformed emails with no headers

_thread_context is now keyed by this thread root. The full References
chain is accumulated on each inbound message so outbound replies carry the
complete header. thread_id is propagated through send(),
send_document(), and send_image() via metadata.

get_chat_info() no longer performs a context lookup — the
chat_id → thread_id mapping is one-to-many and get_chat_info has no
external callers, so it now returns a static response with subject: "".

How to test

1. Configure an email adapter and send two unrelated emails from the same address
2. Reply to each — verify each reply has the correct Subject, In-Reply-To,
   and References headers matching its own thread (not the other)
3. Send a reply chain 3+ deep — verify References accumulates all
   Message-IDs in order

Unit tests: pytest tests/gateway/test_email.py -v (79 tests, all passing)

Platforms tested

Linux

[Copilot]

Pull request overview

This PR fixes incorrect email threading by keying the EmailAdapter’s internal thread context by the canonical thread root (root Message-ID) rather than by sender address, preventing unrelated emails from the same sender from clobbering each other’s reply headers.

Changes:

• Added _extract_thread_id() to compute a stable thread root from References → In-Reply-To → Message-ID → local UUID fallback.
• Updated inbound email parsing/dispatch to compute and propagate thread_id, store per-thread context, and accumulate References.
• Updated outbound send paths (send, send_image, send_document) to accept metadata.thread_id and use it for correct subject + threading headers; updated/added tests accordingly.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
gateway/platforms/email.py	Implements thread_id extraction/propagation and switches reply context to per-thread storage keyed by root Message-ID.
tests/gateway/test_email.py	Adds/updates unit tests to validate thread ID derivation, context keying, References accumulation, and metadata-based thread routing.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

send_document() accepts reply_to but never uses it (it isn't forwarded to _send_email_with_attachment()), so attachment replies can't set In-Reply-To/References based on an explicit reply_to like send() does. Consider threading reply_to through to _send_email_with_attachment (and using it to set original_msg_id), so document sends behave consistently with plain-text sends.

[buzz-code]

Pre-existing gap - _send_email_with_attachment never accepted reply_to_msg_id before this PR either. Out of scope here; tracked as a follow-up.

[Copilot]

Now that _thread_context is keyed by per-thread Message-ID roots, it can grow unbounded as new threads arrive (previously it effectively bounded to sender addresses). To avoid long-lived adapters accumulating memory, consider adding an eviction policy (LRU/TTL/max-size) similar to other platform caches, or periodically trimming old thread entries.

[buzz-code]

Valid. The old sender-keyed dict was implicitly bounded by unique senders; Message-ID keying does grow faster. Other adapters handle this with inline eviction (no shared utility exists). Will address in a follow-up — not blocking this fix.

[teknium1]

Thanks for isolating a real email-threading problem. Current main still keys _thread_context by sender at plugins/platforms/email/adapter.py:867 and resolves it by recipient at :933, so the stated clobbering scenario remains valid.

Problems

• The PR modifies the former gateway/platforms/email.py; commit 560010547 moved the live adapter to plugins/platforms/email/adapter.py. The implementation and imports need to be ported to that plugin surface.
• Current native multi-image sends remain outside the proposed propagation: plugins/platforms/email/adapter.py:1023-1031 does not forward metadata to _send_email_with_attachments, which still looks up context by sender at :1047.
• The added tests do not send replies for two distinct roots from the same sender, so they do not directly prove the reported overwrite is prevented.

Suggested changes

• Port the thread-root and metadata changes to plugins/platforms/email/adapter.py, including native multi-image attachments.
• Add a two-thread same-sender regression that asserts each outbound Subject, In-Reply-To, and References chain.

Automated hermes-sweeper review.

[GottZ]

This was generated by AI during triage.

Summary

Three PRs address the same-sender email-thread overwrite: #11185 introduces canonical root Message-ID context and References-chain propagation but targets the retired gateway adapter, #11418 stores multiple contexts without plumbing identity into outbound sends and also targets the retired adapter, while #73189 updates the live plugin and propagates explicit reply targets through text and attachment paths.

Related pull requests

• #11185 related — (+208/-26) — superseded implementation direction: The canonical thread-root key and accumulated References chain directly address context clobbering, but the diff modifies the retired gateway/platforms/email.py surface and omits the live plugin's native multi-image path. Despite the keep_open review on #11185, #73189 is the better consolidation base because its diff changes the currently registered adapter; #11185's root-ID and References-chain design should be carried over before closure.
• #11418 related — (+174/-13) — duplicate with an incomplete fix: The tuple-keyed store preserves concurrent contexts, but outbound methods still call lookup without a thread identifier and therefore select the latest message from the sender, reproducing the reported mis-threading. Despite the keep_open review on #11418, the diff neither updates the live plugin nor proves distinct outbound headers, so it should not remain the merge candidate.
• #73189 related — (+85/-13) — preferred live-surface base, requiring regression coverage: The diff updates plugins/platforms/email/adapter.py, preserves multiple Message-ID contexts per sender, and forwards reply_to through text, document, and native multi-image attachment sends, directly covering the active clobber paths. It should additionally test two same-sender replies end to end and adopt #11185's stable root-ID/full References-chain handling so deeper replies remain associated with one conversation.

Duplicates

#11185, #11418, and #73189 substantially overlap on replacing the single context per sender; #11418 is the weakest duplicate because its outbound fallback still cannot identify the intended conversation, while #11185 contains useful root-thread semantics for incorporation into #73189.

Suggested consolidation

Merge #73189 after adding a two-thread same-sender outbound regression and incorporating #11185's canonical root Message-ID plus full References-chain propagation. Then close #11185 as superseded by the live-plugin implementation and #11418 as a duplicate whose latest-per-sender outbound lookup does not resolve the root cause.

Cross-PR triage: Reviewed 3 pull requests and 0 issues in this complex. Each diff was read against this issue; Assessment working set: 43 kB of PR diffs, 7 kB of issue/PR text, 4 kB of discussion (4 comments), 0 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.