The line worth reading twice sits inside the heartbeat goroutine, where the return value of `Extend` is assigned to the blank identifier and dropped [8]. Nothing in the running job learns that its lease is gone. The worker keeps generating the report, and the loss only surfaces later, when `Complete` fails and the code wraps the error as `ErrLeaseLost` [11]. The blank identifier is carrying a lot of load there.
Cost out the two constants and you can see how much slack that leaves. The claim takes a two-minute lease; the ticker fires every 45 seconds [8]. Claim at t=0 and the lease expires at t=120. A tick that fails at 45 is survivable, because the tick at 90 renews with 30 seconds to spare. Two consecutive failures are not: the lease dies at 120 and the next attempt arrives at 135, fifteen seconds late [15]. One transient error against the lease store gets absorbed. Two in a row hand the occurrence to a second worker while the first is still writing.
That is why `WriteOnce` has to be a separate interface rather than a comment in the worker [10]. The failure order that matters is commit-then-die: the report store commits, the process terminates before acknowledging the message, the queue redelivers, and the second attempt must observe the committed report instead of publishing or emailing it again [10]. Deduplicating the trigger does nothing for that, because both deliveries are the same logical run.
The retry path has a ceiling I would raise. Delay is `1<<min(attempt,6)` seconds [9], so it doubles up to 64 seconds and the first seven attempts consume 127 seconds in total [16]. If the upstream a report depends on is down for an hour, a 64-second cap means roughly 56 wake-ups in that hour [18], each one claiming a lease and failing. Fine for a flaky S3 call. Wasteful against a dependency with a maintenance window.
The 15 minutes is a claim about someone else's platform [1], and the author is explicit that the portable part is the envelope and the claim protocol rather than any SDK [6]. For the pattern to transfer you need exactly two primitives underneath it: an insert that is atomic on the occurrence key, so a doubled trigger loses the race instead of starting a second run [4], and a lease you can extend by key and lease ID from inside the worker [6]. A unique index and an `UPDATE ... WHERE lease_id = $1` will do both. A queue that offers only a fixed, unextendable visibility timeout will not, whatever its docs call the timeout.
In my context this is the right trade, and the reason is scope rather than throughput: the trigger shrinks to something you can read in one sitting [3], and the job's progress becomes a row you can query instead of a log line you have to interpret. The one change I would make before shipping it is to have a failed `Extend` cancel the job context, so the first worker stops on its own rather than discovering the problem at `Complete` [8][11].
