mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-08 04:32:42 +00:00
Marc-André Bombeck
ad62fe229f
The previous race-reconciliation block compared post-insert rows in the DB against the rows we attempted to insert, downgrading any "inserted-but-not-stored" entries to "duplicate". Under standard Postgres semantics that branch never fires: `skipDuplicates` absorbs duplicate-key conflicts but the row is still present in the table (written by the other batch that won the race). So every attempted row was "stored" and the loop ran as a no-op, leaving the per-entry envelope inconsistent with the aggregate counts when two batches collide. The v1.5 iOS sync cursor depends on the envelope sums matching the aggregate counts to checkpoint correctly. Pragmatic fix: trust `createMany.count` for the aggregate `insertedCount` and downgrade exactly `toInsert.length - insertedCount` per-entry "inserted" statuses to "duplicate". The post-fix loop no longer touches `insertedCount` (it was already correct from createMany) so the count cannot drift negative. Order doesn't matter for the client — both statuses checkpoint past the row and the DB ends up with the same single-copy state. Concurrent-write integration test asserts the three invariants the iOS sync cursor relies on: per-entry sums equal aggregate counts, aggregate counts stay non-negative, and the DB row count matches the combined `inserted` total.