Problem
seenMessages is in-memory only. On daemon restart/reload (source.js launchListener) it's
rebuilt empty, so any history that replays through the gateway re-writes rows for messages
already committed → same-uuid duplicates.
Fix
Seed the seen-set from committed part_ids on startup (mechanism exists in backfill's
scanExistingPartIds). Scope it per conversation, lazily — seed a conversation's part_ids
on first replay, not the whole cache up front, since a large cache holds millions of part_ids
and a global preload would be a memory/scan problem. Bounded LRU or a bloom filter are
alternatives if per-conversation is still too heavy.
Done when
Restarting the daemon and replaying prior history produces no same-id duplicates, without
loading the full cache's part_ids into memory.
Problem
seenMessagesis in-memory only. On daemon restart/reload (source.jslaunchListener) it'srebuilt empty, so any history that replays through the gateway re-writes rows for messages
already committed → same-uuid duplicates.
Fix
Seed the seen-set from committed
part_ids on startup (mechanism exists in backfill'sscanExistingPartIds). Scope it per conversation, lazily — seed a conversation's part_idson first replay, not the whole cache up front, since a large cache holds millions of part_ids
and a global preload would be a memory/scan problem. Bounded LRU or a bloom filter are
alternatives if per-conversation is still too heavy.
Done when
Restarting the daemon and replaying prior history produces no same-id duplicates, without
loading the full cache's part_ids into memory.