Background jobs / Ownership explorer

Worker Ownership, Leases & Fencing

The lease expired and a replacement started. What stops the original worker from waking up and writing anyway?

Interactive calculations run in your browser; the initial example is pre-rendered. There are no accounts, uploads, or live queue connections. Inputs stay in page memory; the site does not persist them, put them in URLs, or send them to analytics. A worksheet download includes only what you explicitly export.

Set the ownership timeline

Original active work (seconds)

The pause adds wall-clock time to this amount of work.

Lease / visibility duration (seconds)

Temporary ownership; expiry does not stop a process.

Heartbeat cadence (seconds)

A heartbeat at the exact expiry boundary is too late.

Pause starts at (seconds)

No pause if the original work has already completed.

Pause duration (seconds)

No work or heartbeats during the pause; zero disables it.

Replacement work (seconds)

Worker B renews reliably and then writes once.

Resource enforcement

Current epoch is a stronger, explicitly registered resource contract.

Shutdown signal at (seconds, optional)

Blank disables shutdown; zero sends the signal immediately.

Shutdown grace (seconds)

After this grace the original worker is forcibly stopped.

Ownership timeline

Replacement completed; inspect how the old attempt was contained

Applied increments

One logical intent

Takeover

13 s

After the last valid renewal

In-flight overlap

5 s

Includes a paused original attempt

Original attempt ends

26 s

Work finished; write may be rejected

Protected-resource write decisions
Time	Worker / token	Decision	Resource evidence
18 s	Worker B / 2	Accepted	Increment applied under current-epoch enforcement.
26 s	Worker A / 1	Rejected	Token 1 does not match registered epoch 2.

A fence is checked by the protected resource, not enforced by wishful thinking at the worker. Try the watermark race: A writes before B exposes token 2, so both increments are accepted. Registering the current epoch closes that particular window only under the stronger modeled contract.

Lease, pause, shutdown, and write events in clock order
Time	Actor	Event
0 s	Worker A	Lease acquired with token 1; expires at 10 s.
3 s	Worker A	Heartbeat accepted; lease now expires at 13 s.
4 s	Worker A	Process paused until 18 s; no work or heartbeats.
13 s	Worker B	Expired lease taken over with token 2. The protected resource registers epoch 2 now.
18 s	Worker A	Process resumed; local work continues even if ownership was lost.
18 s	Worker A	Heartbeat rejected: ownership already lost. This zombie attempt does not stop.
18 s	Worker B	WRITE ACCEPTED: Increment applied under current-epoch enforcement.
26 s	Worker A	WRITE REJECTED: Token 1 does not match registered epoch 2.

Ownership is not the same as stopping execution

A visibility timeout or lease allows another attempt to start; it does not revoke the old process's CPU or an external request. Compare no enforcement, a last-write fencing watermark, and an explicitly registered current epoch. Then shorten shutdown grace to see why stopping polling, renewing in-flight ownership, finishing work, and recording completion are separate concerns.

Assumptions and limits

Two attempts perform one non-idempotent increment on a modeled protected resource. These are virtual seconds, not a broker or a network simulation.
Heartbeats use a fixed cadence. A pause suppresses heartbeats and work; missed heartbeats are not replayed. The old worker deliberately ignores failed renewals.
Expiry and forced termination take precedence over a write at the same second. Replacement writes precede original writes on a tie. The replacement renews its lease reliably.
A monotonic watermark rejects tokens older than a previously accepted write; it cannot reject an old owner before the newer token reaches the resource.
The stronger current-epoch option assumes the resource atomically registers ownership changes and checks that epoch on every write. A token that a resource does not check offers no protection.
Graceful shutdown stops new polling and keeps heartbeats for the one in-flight job. Forced termination prevents this model's not-yet-started write, not an external request already in flight.
A successful current-owner write and acknowledgement are one modeled completion. Lost acknowledgements and provider idempotency are separate contracts explored in the other labs.