The dev reset-demo-data CronJob intermittently produced one Error pod per
run with `invoices_pkey` duplicate-key violations. The CTO analysis
(traced in GRO-2136) concluded the race is between the reset image's
three-step chain and a concurrent same-PRNG seeder (the dev
seed-test-data Job being recreated at the top of the hour by Flux).
GRO-2123 added `pg_advisory_lock(0x47524f4f)` around `runSeedBody`,
but `reset.ts` (DROP TABLE … CASCADE) and `drizzle-kit migrate`
ran as separate processes outside that lock — so a concurrent locked
seed could still interleave with the reset's drop+recreate, leaving
two same-seed writers emitting identical invoice ids (the
Mulberry32(seed=42) stream is fully deterministic per process).
This commit makes the whole chain a single locked unit:
- `reset.ts` now takes the same advisory lock and runs DROP → migrate
→ runSeedBody under a single Postgres session (max: 1). The lock
spans the entire chain, so any concurrent `seed.ts` invocation
(via the seed-test-data Job or CI) blocks until the reset finishes.
- `packages/db/package.json` `reset` script is now a single
`tsx src/reset.ts` invocation — `drizzle-kit migrate` no longer
runs as a separate un-locked process.
- `withSeedAdvisoryLock`, `runSeedBody`, `getProfile`, `profiles`,
`SEED_ADVISORY_LOCK_KEY`, and the `SeedProfile`/`ProfileConfig`
types are now exported from `seed.ts` so `reset.ts` can use them
while preserving the deterministic seed contract.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Flea Flicker
1153ccc556