Guard read outside the write's transaction

What goes wrong

The condition that authorises a write is read before, or outside, the transaction or lock that serialises the write itself. Between the read and the commit another writer changes that condition, so the write proceeds on an answer that is no longer true. The author relies on the check and the write being one indivisible decision when they are two.

Example

A rule that one bound stay below another is checked, then written; two edits that each pass separately commit together and leave the stored pair invalid.

Not to be confused with

Not the check-then-create race, which is the narrow case of an existence test before an insert; here any authorising condition, including ordering rules, ownership and in-flight flags, is read outside the region that protects it.

Discovered by

@sks24git GitHub

Field notes · 14

@sks24git2026-11-03beat 2 review rounds

A design note let a node that missed its heartbeat lose its lanes, but only the old owner checked who owns them. A node that pauses after its check and wakes later still writes next to the new owner.

Take over and write under one lock. A check by the old owner alone is check-then-act.
Fence every write, not just one. Accepts and decisions race the same way issues do.

@sks24git2026-11-03beat 2 review rounds

A design moves cleanup out of the shared lock into its own job, but the job never takes the lock hand-out uses. Cleanup drops a claim made a moment ago, and a live worker runs with nothing tracking it.

Give every writer of a record the same lock. Moving one writer out of a big lock opens a race with the rest.

@sks24git2026-11-02beat 1 review round

A fix for a stale tab read the stored value first, then took the row lock to write. A change landing between the two still got wiped, and a failed extra read turned every save into an error page.

Check under the same lock you write under. A read before the lock is a guess, not a guard.
Read only when the request needs it. An extra read on every path is one more way every path fails.

@sks24git2026-11-01beat 1 review round

A long background pass left a shared lock, but a peer still inserts the same row under that lock. The pass sends a paid request, then its own insert hits the unique key and the step fails.

Re-check the row right before the paid call. After you drop a shared lock, a peer can claim the key during your slow reads.

@sks24git2026-10-30beat 2 review rounds

A test deleted rows that a live background worker was still writing children for, so each fix chased one more child table or one more late write. The race closed only when cleanup stopped deleting and retired the rows.

Do not delete what a live worker still owns. Retire it in place, so a late write has nothing to collide with.

@sks24git2026-10-29

A guard checks that the user is idle, then waits on a network call, then acts. The user starts typing during the wait, and the automatic prompt lands on top of their draft.

Never await between a check and the act it guards. Fetch first, then check and act in one step.
Keep the network out of end-of-turn hooks. A stalled host stalls the session.

@sks24git2026-10-25beat 1 review round

A restart runbook checked a status snapshot for running jobs, but nothing stopped the scheduler from admitting a new job after the read. The restart kills that job whenever the window hits.

A read is not a freeze. Checking state without stopping admissions leaves a race the restart loses.
Ship the switch before the runbook. A procedure that needs a pause needs a pause control.

@sks24git2026-10-16

A delivery mark is accepted only while the item is still open, and the closing message requires that mark. Close the item between send and mark, and the mark is refused, so the closing message never goes out.

Record delivery against what was sent, not current state. A mark that rechecks state loses the race with a close.
Test a close between send and ack. The happy path never crosses it.

@sks24git2026-10-15

A worker starts a paid follow-up job before it re-checks that it still owns the record it is settling. If another worker took the record over, both start the job, and one result is never read.

Claim the row, then call out. Take ownership with a guarded write before any side effect.
Test the lost-ownership branch. An untested guard can be deleted while every test stays green.

@sks24git2026-10-09

A data wipe counts rows holding locked funds and refuses if any exist, but takes no lock before deleting. A row an old server commits in that gap gets wiped, and its funds stay locked forever.

Lock the table before you check it. A count without a lock is stale by the next statement.
Assume old servers still write during a migration. Rolling deploys keep them serving.

@sks24git2026-09-27beat 1 review round

A dry comparison run is judged when it lands, against state a live run changed after launch. When the live run lands first, the slower engine's picks all count as refused and the faster one looks best.

Judge a snapshot as of its input. A check against live state punishes whoever lands last.
Race the slow path in the test. Land the other writer first, then the one under test.

@sks24git2026-09-10beat 2 review rounds

A membership check read its answer before taking the lock its writers commit under, while a sibling path inserted the same row under that lock. The race ends in a duplicate-key abort that rolls back the whole invite.

Read under the lock you write under. A check outside the writer's lock is a guess by the time you insert.
A parent-scope lock does not serialize child-scope writers.

@sks24git2026-09-10beat 1 review round

Two settings fields must stay ordered, and the check reads them outside the write transaction. Two concurrent edits, one raising the floor and one lowering the ceiling, both pass and the loser dies on the constraint.

Validate a cross-field rule where the write is serialized. A read outside the transaction proves the pair only for one writer.

@sks24git2026-09-10

Submit stayed enabled while a debounced lookup was still in flight, so a key was minted for one body and the field then resolved into another. A retry sends the new body under a new key.

Block submit while any field is still resolving. An idempotency key covers the body it was minted for and nothing else.