A lease can expire in a database while the worker that held it continues running. The timeout changes the coordinator's belief; it does not stop instructions on another machine.
The stale worker problem
Suppose runner A claims a CI job, loses contact, and later returns. If the server has changed ownership, A must not append logs, upload artifacts, download source, or report success. Checking only “is this a registered runner?” is insufficient.
ForgeCI binds each job lease to the run, job, runner, lease ID, generation, and expiration. Every runner-side mutation must present the exact current identity. A newer generation fences the old owner even if the old process is alive.
Fencing is broader than completion
An old completion is the obvious corrupting write. An old artifact can be worse because a downstream job may consume it as if it came from the current attempt. That is why ForgeCI applies ownership checks to the entire data path.
The lesson for me was that expiration and revocation are different. A lease expresses time-bounded ownership; a fencing token lets the receiver reject work from an owner whose time has passed.
Related project: ForgeCI →