Distributed Lock Service · View 15 of 26 · 5 · Runtime
What happens
- Holder A is granted token 41, writes, then stops dead for 22 seconds: a garbage-collection pause, a VM migration, a throttled container. From outside that is indistinguishable from a crash.
- Its session lapses, etcd commits the revocation, and B is granted token 57. B writes and the resource's high-water mark moves to 57.
- A resumes believing it holds the lock and writes with 41. The resource rejects it. A's library notices its deadline passed and calls onFence, but only after the write was attempted.
Why nothing upstream fixes this
- A cannot check its lease before writing, because the pause can land between the check and the write.
- The service cannot wait longer before re-granting, because any bound it picks can be exceeded by a longer pause. Waiting for certainty turns a safety problem into a permanent availability problem.
What this implies
- An advisory class accepts message 11. That is the whole meaning of advisory, and it is why advisory correctness classes are registered as risks.
