Separate lock ownership from state freshness
What This Concept Is
A lock coordinates writers using the same locking mechanism. A generation identifies a particular acquisition, while a state version identifies the snapshot a change was planned against. Neither replaces the other: a fresh lock can accompany a stale plan, and a fresh plan can be presented by a writer that no longer owns the lock.
Why It Matters Here
The original concurrency lab needs to test rejection, not only successful sequential runs. Reusing an owner name after release is common in automation. Comparing only that name confuses an old operation with a new acquisition. The model adds an increasing token to make this failure visible; it is not a claim that Terraform backends implement this exact token protocol.
Concrete Example
Runner A acquires token (A,1), releases it, then acquires (A,2). A delayed release carrying (A,1) must not clear (A,2). Likewise it must not apply under the new acquisition. The owner is the same string, but the operation is different. The model also rejects a plan with the correct serial from another state lineage: unrelated environments can both be at serial 7.
Common Confusion / Misconception
A lock-file presence is not proof that a process is dead or alive. A timestamp alone cannot justify force-unlock. Local filesystem locking is different from a shared remote backend, and a shared object store needs its supported locking configured. None of these mechanisms prevents a console user or another system from modifying cloud resources.
How To Use It
Record target, lock identity, owner/run, observation time and known process state. On contention, wait or investigate; do not disable locking to make the pipeline green. Before documented recovery, establish that the original writer cannot resume, preserve evidence and coordinate ownership. Use the actual backend's recovery procedure. The teaching model deliberately has no force-unlock operation because it cannot establish real process death.
Check Yourself
Can a new lock make an old plan safe? Why can identical serials identify different states? What prevents a delayed release from clearing a newer lock? What remains outside the lock's protection?
Mini Drill or Application
Run same-owner reacquisition and stale-release cases. Add wrong-owner, wrong-lineage and no-lock attempts, showing rejected operations leave all state unchanged. In the original lock/recovery lab, document the process evidence you would need before recovery; do not present a simulated token as proof of backend behavior.
Read This Only If Stuck
Terraform state locking explains backend support and force-unlock constraints. Local backend and S3 backend document their different mechanisms.
Pro Git supports versioned change and review discipline; the linked HashiCorp documentation governs Terraform behavior.