Marc-André Bombeck 24050d84c7 fix(import): make re-importing the same CSV idempotent and fast ...

Re-uploading a large export with an externalId column ran one
updateMany per row inside a single interactive transaction; on a
9 000-row file that outlived Prisma's 5 s timeout and the request ended
in a 500.

A re-imported externalId row whose stored value, unit, instant, glucose
context and note already match the line is now a duplicate: not written,
reported as skipped / duplicate. Changed rows still update, a tombstoned
one is still resurrected. The existence probes run per measurement type
in chunks of 1 000 keys, and the writes commit in chunks of 200 (creates
via createManyAndReturn, updates as one batch transaction per chunk)
instead of one transaction around the whole file. A failure part-way
leaves earlier chunks written, and re-uploading the same file completes
the rest.

The OpenAPI description now says what a re-upload does, including the
natural-key dedup for rows without an externalId, which it used to call
a duplicate.

2026-09-26 19:58:50 +02:00

..

fixtures/v137

Let a checkup be skipped or pushed back, and remember every outcome

2026-08-14 09:23:58 +02:00

integration

fix(import): make re-importing the same CSV idempotent and fast

2026-09-26 19:58:50 +02:00