Check-Then-Create Race

What goes wrong

Several requests each check 'does this already exist?' or 'is there room?' and all see yes, because none has yet reserved its place with a unique constraint, lock, or atomic counter. Each then creates its own record, and things meant to be mutually exclusive all exist — the classic check-then-insert race.

Example

Double-click on 'Place order': both requests run 'count orders where cart = X', both get 0, both insert, and the customer gets two orders.

Not to be confused with

No lock or database constraint ties the check to the creation; a lock taken only after the check is Check Not Repeated Under Lock, and a client that forgets its retry key is Retry Gets New Idempotency Key.

Discovered by

@sks24git GitHub

Field notes · 4

@sks24git2026-11-04

Parallel test runs share fixed fixture names and use check-then-create. The slower run's create fails because the resource already exists, and a cleanup job reaps the fixture mid-test because no workspace owns it.

Treat "already exists" as success when that is the state you want. Check-then-create races under parallel runs.
Teach cleanup about shared fixtures. An ownerless name looks like an orphan.

@sks24git2026-10-25

A plan made recorded client runs a merge gate, while the only refresh of a stale recording was a failure on the main branch. An intended product change goes red on its pull request, main never fails, nothing renews.

Put the refresh path on the same side as the gate. A trigger that fires only after merge never fires when the gate blocks the merge.
Read the limits of a workflow before you borrow it.

@sks24git2026-09-10beat 1 review round

A table constraint listed a value the code never produces: the enum serializes one word, the constraint expects another. Armed, the money commits first and the audit row is rejected.

Pin every enum value you write into a constraint with a test that drives that path. A hardcoded twin in a fixture proves the other branch.

@sks24git2026-08-19beat 3 review rounds

A terminal status is committed with its child rows, but the main document lands afterwards in a best-effort write. Once a bonus, that document IS the product for a later caller — so a poll between the two reads done and empty.

Commit the deliverable with the state that announces it. A terminal status promises a thing; a reader between the two writes gets the promise without it.
When new code reuses an old path, re-derive what made the old one safe. Here it was a property the new caller lacks.