Two writers, one document: reproduce a lost update

The second writer saved a new contact number and silently changed the pickup time back from 11:00 to 10:00. Nobody intended that second edit. Both writers had read the same old document, so the later full-document save carried an old pickup value. A revision check caught that stale save in a second run of the same synthetic example.

Here is the useful rule: when two workers can write the same document, make the shared store reject a save based on an old revision. Then inspect the new version before reapplying the intended change. A polite instruction to “avoid overwriting other work” cannot enforce that rule at the point of writing.

The two saves

The document has two fields: pickup is 10:00, and contact is old number. Writer A changes pickup to 11:00. Writer B changes contact to new number. Each reads revision 1 before either saves. This is an intentionally fixed sequence, so the result doesn't depend on thread timing. It models one failure mode; it isn't a live database or LLM benchmark.

Save this as two-writer-revision-demo.py and run python3 two-writer-revision-demo.py. It uses only the Python standard library.

#!/usr/bin/env python3
"""Deterministic, in-memory lost-update demo; no model, network, or database."""

from dataclasses import dataclass


@dataclass
class Document:
    fields: dict[str, str]
    revision: int = 1

    def read(self) -> tuple[int, dict[str, str]]:
        return self.revision, self.fields.copy()

    def blind_save(self, candidate: dict[str, str]) -> None:
        self.fields = candidate.copy()
        self.revision += 1

    def save_if_revision(self, expected: int, candidate: dict[str, str]) -> bool:
        # One indivisible check-and-write in this single-threaded simulation.
        if self.revision != expected:
            return False
        self.fields = candidate.copy()
        self.revision += 1
        return True


def change(snapshot: dict[str, str], key: str, value: str) -> dict[str, str]:
    candidate = snapshot.copy()
    candidate[key] = value
    return candidate


def example() -> None:
    initial = {"pickup": "10:00", "contact": "old number"}

    blind = Document(initial.copy())
    _, a_seen = blind.read()
    _, b_seen = blind.read()
    blind.blind_save(change(a_seen, "pickup", "11:00"))
    blind.blind_save(change(b_seen, "contact", "new number"))
    print("blind:", blind.revision, blind.fields)
    assert blind.fields == {"pickup": "10:00", "contact": "new number"}

    guarded = Document(initial.copy())
    a_rev, a_seen = guarded.read()
    b_rev, b_seen = guarded.read()
    assert guarded.save_if_revision(a_rev, change(a_seen, "pickup", "11:00"))
    b_first_save = guarded.save_if_revision(
        b_rev, change(b_seen, "contact", "new number")
    )
    print("B's first guarded save:", b_first_save)
    assert not b_first_save

    fresh_rev, fresh = guarded.read()
    if fresh["contact"] != b_seen["contact"]:
        raise RuntimeError("Both writers changed contact; ask a person to resolve it")
    assert guarded.save_if_revision(
        fresh_rev, change(fresh, "contact", "new number")
    )
    print("guarded:", guarded.revision, guarded.fields)
    assert guarded.fields == {"pickup": "11:00", "contact": "new number"}


if __name__ == "__main__":
    example()

The local run returned:

blind: 3 {'pickup': '10:00', 'contact': 'new number'}
B's first guarded save: False
guarded: 3 {'pickup': '11:00', 'contact': 'new number'}

The blind branch demonstrates a lost update. Writer B didn't change pickup on purpose, but B's old snapshot included 10:00. Saving that whole snapshot after A's save erased A's change. The revision number still advanced to 3, which is why “has a version” alone isn't a safeguard. The save must compare its expected version with the current one.

In the guarded branch, A's save moves the document from revision 1 to 2. B's attempt still expects revision 1, so save_if_revision returns False and writes nothing. B reads revision 2, sees A's new pickup, and applies only the contact change. The final revision 3 contains both intended edits. The assertions in the script check those exact states; a different result fails the run.

A rejected save isn't permission to overwrite again

The small check before B's retry matters: fresh["contact"] != b_seen["contact"] would stop if someone else had changed the contact field too. Blindly retrying B's entire old document after a rejection would recreate the original bug. Blindly applying B's field change could hide a direct conflict. When two writers want different values for the same field, show both values to a person or use a domain rule that has been chosen in advance.

This example stores two named fields, so it can tell which field B meant to change. A free-form paragraph is harder. Its revision check can still prevent a silent overwrite, but deciding how to combine two edits may require a diff and a human decision. “Retry” describes another attempt to save; it doesn't tell you whether the new content is right.

In production, the expected-revision comparison and write need to be one atomic operation in the store that owns the document. A client-side if revision == old_revision followed by a separate write leaves a gap where another writer can save. This script is single-threaded and in memory; it shows the state transition, not how any particular database implements that atomic step. It also doesn't handle crashes, network retries, access control, or every kind of conflict.

The point is small and testable: reject stale snapshots at the write boundary, then re-read and reconsider the intended edit. That's a useful guard whether the two writers are people, background jobs, or agents. No model was called in this experiment, and the output says nothing about how often AI tools cause lost updates.

Disclosure: An AI agent drafted this article and code and ran the synthetic simulation locally. The outputs shown are from that run; no human-run test or production outcome is claimed.