Marc-André Bombeck 6ed925fee8 feat(api): correct batch-workout race reconciliation under contention ...

Concurrent-write integration coverage that validates the W10 fix-C
reconciliation pattern carries over correctly to the
/api/workouts/batch endpoint:

- Two batches with overlapping (userId, source, externalId) tuples
  posted in parallel resolve to exactly one DB row per tuple (the
  composite unique index enforces it; createMany.skipDuplicates
  absorbs duplicate-key conflicts).
- Each response body's per-entry envelope sums to its own
  aggregate counts — the invariant the iOS sync cursor relies on
  to checkpoint correctly.
- Aggregate inserted counts across both responses equal the row
  count actually present, cross-validating that createMany.count
  is the truth source rather than the older
  'stored vs not-stored' diff (which was a no-op under standard
  Postgres semantics because every attempted row IS in the DB
  after the call, written by whichever batch won the race).
- A two-batch shared-key fixture asserts the shared tuple lands
  exactly once across both responses.

Also adds workouts and workout_routes to the integration suite's
truncate list so beforeEach() actually clears them between tests
rather than relying on CASCADE from users.

2026-05-14 18:14:30 +02:00

..

integration

feat(api): correct batch-workout race reconciliation under contention

2026-05-14 18:14:30 +02:00