Ingress threading ignores References header and only links threads via In-Reply-To #4

New Issue

2026-04-27T18:40:56+07:00

codex commented

2026-04-27 18:40:56 +07:00

Summary

The ingress flow implements anti-loop, whitelist, idempotency, and dispatch wiring correctly, but the threading step is incomplete: it only looks at In-Reply-To and ignores References.

Expected flow

IMAP ingress -> check/filter rules -> threading resolution -> save RECEIVED -> dispatch

Within the threading step, the spec says:

if In-Reply-To or References is present, find the parent task in DB and inherit thread_id
otherwise use message_id as the new thread_id

Evidence

requirements.md:73-75 requires parent lookup via In-Reply-To / References
README.md:12 advertises threading via In-Reply-To / References
internal/mail/imap.go:247-283 only extracts In-Reply-To and uses that single header for parent lookup
checkpoints/002-feedback.md:15 already noted that References fallback was still missing

Why this is a problem

Many email clients preserve conversation history primarily through References. When In-Reply-To is absent but References is present, the bridge will incorrectly start a new thread_id instead of attaching the message to the existing conversation.

That breaks the downstream dispatch contract because:

the wrong thread_id is saved on ingress
OpenClaw receives the wrong session_id
thread history retrieval for dispatch can miss prior completed messages

Expected behavior

Parse both In-Reply-To and References
When In-Reply-To is missing, fall back to the most relevant message ID from References
Reuse the parent thread_id before dispatching

Impact

Thread continuity is broken for valid reply emails that rely on References instead of In-Reply-To, causing context loss in dispatch.

## Summary The ingress flow implements anti-loop, whitelist, idempotency, and dispatch wiring correctly, but the threading step is incomplete: it only looks at `In-Reply-To` and ignores `References`. ## Expected flow `IMAP ingress -> check/filter rules -> threading resolution -> save RECEIVED -> dispatch` Within the threading step, the spec says: - if `In-Reply-To` or `References` is present, find the parent task in DB and inherit `thread_id` - otherwise use `message_id` as the new `thread_id` ## Evidence - `requirements.md:73-75` requires parent lookup via `In-Reply-To` / `References` - `README.md:12` advertises threading via `In-Reply-To` / `References` - `internal/mail/imap.go:247-283` only extracts `In-Reply-To` and uses that single header for parent lookup - `checkpoints/002-feedback.md:15` already noted that `References` fallback was still missing ## Why this is a problem Many email clients preserve conversation history primarily through `References`. When `In-Reply-To` is absent but `References` is present, the bridge will incorrectly start a new `thread_id` instead of attaching the message to the existing conversation. That breaks the downstream dispatch contract because: - the wrong `thread_id` is saved on ingress - OpenClaw receives the wrong `session_id` - thread history retrieval for dispatch can miss prior completed messages ## Expected behavior - Parse both `In-Reply-To` and `References` - When `In-Reply-To` is missing, fall back to the most relevant message ID from `References` - Reuse the parent `thread_id` before dispatching ## Impact Thread continuity is broken for valid reply emails that rely on `References` instead of `In-Reply-To`, causing context loss in dispatch.

claudecode referenced a pull request that will close this issue

2026-04-28 05:11:32 +07:00

Add References header fallback for thread resolution #13

thuanle referenced this issue from a commit

2026-04-28 05:18:32 +07:00

fix: remove out-of-scope plan files and gofmt test file

codex referenced this issue

2026-04-28 05:21:17 +07:00

Add References header fallback for thread resolution #13

claudecode closed this issue

2026-04-28 05:39:03 +07:00

Sign in to join this conversation.