SWARM · LEASES AND FENCING TOKENS
Agent swarm: elect one owner for a duplicated task
Broadcast one refund task to two workers, stall the first one, and see whether a lease, renewal and a fencing token keep the refund to exactly one.
Your experiment
Task T-91 refunds order 7731 and must run once. Worker A takes it at 0 s, worker B at 0.5 s, and the work takes 5 s. Start with a 4 s lease and a 5 s stall in A, then lengthen the TTL, stop renewal, remove the stall and add a fencing token.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, Speed changes the pace and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Deterministic model: A renews on whole seconds while it is running and not stalled; B polls on whole seconds and takes the lease as soon as it lapses; the ledger checks a fencing token only when a write arrives. Clocks are perfect and the lease store never fails. Real systems also need idempotent effects, because a lease alone cannot stop a stalled owner from finishing.
Two receivers, one refund
Task T-91 refunds order 7731. It is broadcast twice, so worker A receives it at 0 s and worker B at 0.5 s; the work takes 5 s. With Ownership mechanism set to None: every receiver runs the task, both workers refund the customer. With the opening Compare-and-set lease, A takes a 4 s lease and B polls. But A stalls for 5 s from 1 s, a long garbage-collection pause, so it cannot renew; the lease lapses at 4 s, B takes it and refunds at 9 s, and A wakes up and refunds again at 10 s: DUPLICATE EFFECT with 2 refunds.
The TTL has to outlast the stall
Lease TTL and renewal only apply to the lease mechanisms. Raise the TTL to 6 s and A resumes at 6 s and renews at that instant, so B never takes over: ONE OWNER. At 5 s the lease lapses one second before A resumes. Clear Owner renews the lease every second while running and the lease must cover the whole run: A finishes at 10 s, so a 10 s or 12 s TTL is safe and a 4 s TTL is not. Set Worker A stall to 0 and a renewing 4 s lease is enough. Set it to 8 s and an 8 s TTL fails: A resumes only at 9 s, so the lease must last at least 9 s.
A fencing token rejects the stale write
Choose Lease plus ledger-checked fencing token and restore the opening values. A holds token 1; B takes the lapsed lease with token 2 and writes its refund first at 9 s. When the stalled A finishes at 10 s, the ledger has already seen token 2 and rejects token 1: ONE OWNER with 1 rejected write. The protection does not depend on guessing the longest pause.
Where fencing is not enough
With the fencing token, set the stall to 0 and clear renewal. The lease lapses at 4 s while A is still working; B takes token 2, but A finishes at 5 s and writes first, when the ledger has not yet seen token 2, so it is accepted. B then writes at 9 s with the newer token: two refunds. A token only blocks writes older than one the resource has already seen; the new owner must check whether the work was done, or the effect itself must be idempotent.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time step through the duplicate delivery, the claim, the lease timeline and each ledger write across sixty seconds; the table lists each worker, finish time, token and write outcome. Clocks are perfect, renewals happen on whole seconds and the lease store never fails or partitions. The model isolates why a lease is a timeout, not a guarantee.