Skip to content
C.W.K.
Lesson 02 of 06 · published

One Motion Under One Lease

~12 min · concurrency, leases, records, design

Level 0Wet Clay
0 XP0/40 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete

Four Steps That Must Not Be Interleaved

Landing a finished piece of work is four things: stamp the record that lives with the material, commit it together with that stamp, push it, and write the log entry that says this happened. Any one of them alone is unremarkable. What matters is that no other landing may happen between them.

If another session slips a landing in between your stamp and your push, the repository and the record now describe different histories, and nothing in either one says so. That is the worst class of data problem: silent, plausible, and discovered months later by someone trying to answer an unrelated question.

Be exact about what the lease buys, because it is easy to over-claim. It excludes other landings. It does not make the four steps atomic, and the difference is not academic: if your own process dies after the push and before the log entry is written, you get the identical split history with nobody else involved — the material says it landed, and the workshop's log does not. Serialization is not transactionality. What closes that remaining gap is not a bigger lock but a reconciliation pass — a view that walks the repository against the record and reports where the two disagree.

The Lease, and the Lock It Is Not

The mechanism is a lease held on the target repository for the duration of those four steps. The word is borrowed for the property that matters: a holder who never comes back can be taken off it. Be precise about what is borrowed. In distributed systems a lease is time-bounded: it expires unless the holder renews it, and expiry is how a dead holder is removed. This workshop keeps the property and drops the timer, on purpose — a slow interactive session is not a dead one, and a timer cannot tell the two apart.

Compare the plainest kind of lock, the one this track's busy day kept tripping over: version control's own index lock, a file with no expiry that a crashed process leaves behind. It holds until someone notices, and the recovery is a human finding the stale lock and deciding it is safe to delete. Many locks avoid that with a timeout, or by dying with their process; that one does neither. This lease is held until released, or until someone breaks it deliberately and the break is itself recorded, which turns "the holder never came back" from an incident into a delay. Given that these holders are interactive sessions on laptops that get closed, that recorded way out is load-bearing rather than theoretical — and it is a design choice of this workshop, not what the word means everywhere.

Verification Is Part of the Motion Too

One more coupling belongs here: the landing refuses to proceed unless the latest recorded verification for this unit of work passed. Not a suggestion in a document — the command reads the event and exits if it is absent or failed. (Until 2026-10-13 any earlier pass would do; the previous track's lesson on a log with teeth tells how that gap was found.)

There is an override, and using it writes that fact into the record. That combination is the shape to aim for everywhere: the escape hatch exists, because a guard with no override gets removed the first time it is wrong at an awkward hour, and taking it is never invisible.

You could ask why the verification check lives inside the landing command at all, rather than as a separate step people are asked to run first. That separate arrangement is exactly the one that rotted in the previous track: when verification is independent of the landing, a step that costs nothing to skip eventually gets skipped. Rather than asking for the order to be honored, make the wrong order unable to proceed.

Group the steps that must agree with each other under one held lease, and give the lease a recorded way to be broken. The grouping is what keeps two records from telling different stories; the recorded break is what keeps a closed laptop from stopping everyone else's work until somebody investigates.

Code

The landing, with its couplings visible·python
def land(unit_id: int, note: str, force_unverified: bool = False):
    # 1. TEETH: no green verification, no landing. The override is
    #    itself recorded - possible, never accidental.
    #    The LATEST verification must have passed (since 2026-10-13;
    #    before that, any earlier pass was accepted).
    if not latest_verification_passed(unit_id) and not force_unverified:
        raise SystemExit("the latest verification did not pass - run it")

    # 2. THE LEASE. Held across everything below. The holder is an
    #    interactive session on a laptop that can be closed mid-run,
    #    so recovery is an explicit break that LEAVES A RECORD - not a
    #    timer, which would also release a holder that is merely slow.
    lease = acquire_lease(repo="content")
    try:
        base = choose_base(repo)          # lesson 4: a behind checkout
                                          # is fast-forwarded first
        stamp_record(unit_id, note)       # lives WITH the material, so
                                          # it rides INSIDE the commit
        sha = scoped_commit(repo, base,   # lesson 3 of this track
                            paths=pipeline["land_paths"], msg=note)
        push(repo)
        write_log_entry(unit_id, "landed", commit=sha)
    finally:
        release_lease(lease)


# Why all four are inside: if another landing could interleave
# between `stamp_record(...)` and `push(repo)`, the repository and
# the record would describe different histories, and NEITHER of
# them would say so. Silent, plausible, found months later.

External links

Exercise

Find a multi-step operation in your system where the steps write to different stores — a database and a search index, a repository and a ticket, a deployment and an announcement. Write down what a reader would conclude if the operation stopped between each pair of steps. Then decide which of those intermediate states you can tolerate and which need to be grouped under one held resource.
Hint
The dangerous intermediate states are the ones that look complete. A half-finished operation that leaves an obvious mess gets fixed; one that leaves two stores each internally consistent and mutually contradictory gets believed by both sides for months.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign in — Please sign in to comment.

No comments yet — be the first.