feat(search): index mailing list traffic - #700
Conversation
roborev: Combined Review (
|
|
this one was hard. unsure if this is the best way to build it. |
ac66672 to
f358860
Compare
roborev: Combined Review (
|
roborev: Combined Review (
|
Mailing-list searches and views must not silently change scope or fail after the UI advertises them. Decoded display names could corrupt stored list IDs, Files exposed a grouping its query engine rejected, and older daemons received list views outside their schema. Parenthesized Gmail list syntax now fails with guidance instead of returning empty results. The published deep-search contract also identifies filters that the runtime rejects. Generated with Codex Co-authored-by: Codex <noreply@openai.com>
roborev: Combined Review (
|
Incremental consumers need the List-ID value whenever its message watermark moves. Without it, a consumer can observe the change but cannot refresh that field from the feed snapshot. The historical repair must also treat blank message types as email, consistent with the rest of the query layer. Otherwise archives imported before message classification keep missing List-ID values after repair. Generated with Codex Co-authored-by: Codex <noreply@openai.com>
roborev: Combined Review (
|
What changed
msgvault repair-list-ids.list:andlist-id:filtering across local, semantic, hybrid, API, and daemon-backed search, with exact scoped filtering for list drill-down and deletion.Why
Mailing-list traffic was searchable only through sender, subject, or body text. That makes a busy discussion list difficult to find, group, and safely act on because its messages can come from many senders. Indexing the canonical List-Id gives every supported local surface one stable mailing-list identity without re-fetching provider data.
Usage
repair-list-idsis dry-run by default. Use--applyto persist the backfill, then rebuild the analytics cache through the normal cache workflow.Fixes #674