Repository navigation
copilot: rollup dedup key uses a per-file occurrence counter, so two journals for one session collide on the same leg index #1051
Description
Found while landing #946 (review B-4 fixture). The rollup dedup key copilot:<sid>:shutdown:<model>:<n> uses a per-file occurrence counter n. When a session has two journal files (e.g. resumed into a second events.jsonl) with the same model, the second file's leg 1 collides with the first file's leg 1 and is deduped away before the reconciliation sweep — one leg silently dropped. Pre-existing (not introduced by #946; #946's residual keys were changed to be timestamp-derived precisely to avoid this class). Fix direction: key rollups by the leg's shutdown timestamp (or per-session counter across files) — that IS a cached-key-shape change for a durable provider, so it requires a CACHE_VERSION bump (see the F4 key-prefix pin test and the carry-forward invariant comment in parseProviderSources). Add a two-journal fixture.
Activity
iamtoruk commentedon Aug 22, 2026
Closing as unreachable: the deep review of #1054 established that two journals for one session cannot both enter discovery (the discovery path dedupes the session before per-file occurrence counters ever see a second journal), so the leg-index collision this issue describes has no reachable trigger. The retargeted #1054 (merged, 67f085a) adopted that analysis explicitly — it kept the
:<n>occurrence keys and took only the lastEventTimestamp ordering for the call timestamp. If a future Codex/Copilot change makes multi-journal discovery reachable, reopen with a repro; the #946 branch's session-store keys make the whole question moot for store-era data anyway.Merge origin/main into feat/copilot-session-store