Problem
The durable onTicketDispatch marker is intentionally claimed before fan-out to external providers. This gives takeover and retry paths at-most-once behavior, but leaves a known crash window: if the process exits after the durable claim succeeds and before a provider accepts the notification, that delivery is not retried.
This trade-off was accepted in PR #238 because the current notification adapters do not expose a provider idempotency key. Claiming after fan-out would allow duplicate notifications when a provider accepts a request but its acknowledgement is lost.
Completion condition
Close this gap when either:
- providers support a stable idempotency key derived from the durable work-unit ID, allowing safe retries; or
- the lifecycle model separates delivery claim/attempt from a durable delivery-confirmed marker and defines safe recovery for interrupted attempts.
Any implementation should preserve owner/epoch fencing and serialization of lifecycle persistence while preventing duplicate fan-out during takeover.
Problem
The durable
onTicketDispatchmarker is intentionally claimed before fan-out to external providers. This gives takeover and retry paths at-most-once behavior, but leaves a known crash window: if the process exits after the durable claim succeeds and before a provider accepts the notification, that delivery is not retried.This trade-off was accepted in PR #238 because the current notification adapters do not expose a provider idempotency key. Claiming after fan-out would allow duplicate notifications when a provider accepts a request but its acknowledgement is lost.
Completion condition
Close this gap when either:
Any implementation should preserve owner/epoch fencing and serialization of lifecycle persistence while preventing duplicate fan-out during takeover.