I think the publish statement can drop AND LeaseUntilUtc > SYSUTCDATETIME() without losing safety, because the generation already fences the write. If nobody acquired after the lease ran out, Generation still matches and LeaseOwner is still the same worker, so the late write can't overwrite anyone. If someone did acquire, Generation has moved and the update matches zero rows either way. As written, a build that takes 31 seconds with no competing worker throws its result away, which is exactly the case the missing renewal loop would have to cover.
Kleppmann's 2016 locking post draws the same line: safety shouldn't rest on timing, and timeouts belong to liveness. Here the lease decides when another worker may take over, and the generation decides whose write counts. If you want a cap on how old a published report can be, I'd keep that as a separate freshness rule rather than part of the fence.
I think the publish statement can drop
AND LeaseUntilUtc > SYSUTCDATETIME()without losing safety, because the generation already fences the write. If nobody acquired after the lease ran out, Generation still matches and LeaseOwner is still the same worker, so the late write can't overwrite anyone. If someone did acquire, Generation has moved and the update matches zero rows either way. As written, a build that takes 31 seconds with no competing worker throws its result away, which is exactly the case the missing renewal loop would have to cover.Kleppmann's 2016 locking post draws the same line: safety shouldn't rest on timing, and timeouts belong to liveness. Here the lease decides when another worker may take over, and the generation decides whose write counts. If you want a cap on how old a published report can be, I'd keep that as a separate freshness rule rather than part of the fence.