Whole-Record Write Without Version Check

What goes wrong

A writer reads a whole record, changes one part and writes the whole thing back (or unconditionally sets a high-water mark, or stamps rows in a sweep) with no version check — no 'write only if it is still what I read', i.e. compare-and-set — that the record's other writers rely on, so a concurrent or later legitimate write is silently erased: the classic lost update.

Example

Two browser tabs each load the settings JSON, change one field and save the whole object; the second save wipes the first tab's change.

Not to be confused with

No version check exists at all, unlike a version token that is present but taken from the wrong place (Laundered Version Token); the writer is not a former owner writing after losing ownership (Ghost Owner Write), and the loss can be sequential as well as concurrent.

Discovered by

@sks24git GitHub

Field notes · 10

@sks24git2026-11-06

A scheduled job looked up which commit the site served from deployment records, then republished it minutes later. Its own deploy wrote a new record, and a slower gated deploy in between got rolled back.

Never pick what to publish from records your own job writes. The next run reads your write back as truth.
Read the target right before you act. A value read minutes earlier is a race.

@sks24git2026-11-05beat 7 review rounds

A guard ran only when a row read as finished, and the other branch updated the row with no state check. If the row finished between the read and the write, the unguarded update undid a result already shown.

Put the state you read into the write's WHERE. A branch picked from a stale read must not act on a row that moved since.

@sks24git2026-11-03beat 3 review rounds

Two workers rebuilt a shared copy by deleting all rows and then inserting fresh ones, with no version check. When their passes overlap, one fails on a duplicate key, or a slow pass writes old values over newer ones.

Give a shared copy one writer or a version. Last commit wins is not newest wins.
Upsert, do not delete then insert. Overlapping passes collide on keys.

@sks24git2026-11-02beat 1 review round

A settings form saved the whole record without checking it was still the version the admin loaded. When two admins edit at once, the later save silently restores stale values, payment details included.

Send the version you read with every full-record save. Refuse it if the record moved.
On a conflict, reload the form. A retry from the stale draft repeats the loss.

@sks24git2026-10-23beat 1 review round

A field-by-field edit read the saved record before taking the lock the full-form writer holds. A full submit that commits in that gap is silently overwritten by the edit's stale copy.

Take the writer's lock before you read what you will rewrite. A snapshot read before the lock is already stale.
Test the race with two connections. A sequential test never sees it.

@sks24git2026-10-16

A job reads a record, waits on slow network calls, then writes the whole record back with one section appended. Any edit a person makes during that wait is overwritten without a trace.

Write from a fresh read, not an old snapshot. A full overwrite erases every edit made since the read.
Keep slow calls out of read-then-write. The gap between them is where lost updates live.

@sks24git2026-10-16beat 1 review round

A cleanup job checks that a record is open, makes two slow network calls, then writes its close with no condition. A worker that closes the record in that gap has its real numbers wiped by blanks.

Put the check in the write itself. A check before slow calls goes stale by the time you write.
Let the owner's write win. A cleanup must never overwrite what the worker recorded.

@sks24git2026-09-10

Every test that armed the new mode asserted a failure, and the only test that provisioned it fully left the switch off. Nothing pinned the state the feature exists to enable.

Pin the success state, not only the refusals. A suite that exercises one side only proves the test exists.
Ask which arm can break the property. The green side is the one nobody armed.

@sks24git2026-09-08beat 5 review rounds

A settings cache published every row it read, with no version check. A slow read that started before an admin edit and finished after it put the old policy back — and the outage fallback kept it.

Make cached publication monotonic by version. A read is not newer because it finished later.
Grep the package for the sibling that solves it. The second copy is the one without the lock.

@sks24git2026-09-06beat 1 review round

A charge job read a snapshot of due rows filtered by status, then operated per row without re-checking. A cancel between snapshot and charge still billed the cancelled subscription.

Revalidate at the write, not the read. A filter at snapshot time is stale by the time the row is touched.