mirror of
https://github.com/ModernRelay/omnigraph.git
synced 2026-06-09 01:35:18 +02:00
6dc4167291
Three independent automated reviews (Cubic P1, Cursor High, Codex P1) flagged a real correctness bug in stage_merge_insert: Operation::Update returns three fields — removed_fragment_ids, updated_fragments, new_fragments — and we were collecting only the latter two into StagedWrite.new_fragments while discarding removed_fragment_ids. That breaks read-your-writes for any merge_insert that rewrites an existing fragment: scan_with_staged combines the dataset's full committed manifest with the staged new_fragments, so the *original* committed fragment (which the rewrite supersedes) and its rewritten version both end up in the Scanner's fragment list. Result: duplicate rows. Fix: - StagedWrite gains `removed_fragment_ids: Vec<u64>` populated from Operation::Update; empty for Operation::Append (which never supersedes existing fragments). - scan_with_staged / count_rows_with_staged take `&[StagedWrite]` instead of `&[Fragment]` so they have access to both fields. - A new `combine_committed_with_staged` helper composes the visible fragment list as `committed - removed + new`, deduping by fragment ID. Also addresses cubic's P3 doc-fab note: the StagedWrite doc comment claimed the type was "used by MutationStaging and the loader" but those callers don't exist in this PR (they're MR-794 step 2+). Reword to "defined here for later integration" so the doc doesn't lie about the current state. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| omnigraph | ||
| omnigraph-cli | ||
| omnigraph-compiler | ||
| omnigraph-server | ||