At-least-once delivery is stated, not implied. Exactly-once processing is not offered, because it cannot be offered across a queue, a worker and an unrelated downstream system without distributed transactions nobody wants.
taskExecutionId is the idempotency key end to end: message id, idempotency record key, and Idempotency-Key header on the downstream call. One identifier, three enforcement points, no translation layer.
The platform guarantees the key is stable and travels; it does not guarantee the downstream honours it. That boundary is drawn deliberately, and it is the single most important thing a task author must understand.
Why the claim record is not enough
The trace shows the hard case: Worker 1 completes the side effect and dies before recording it. The idempotency record says IN_PROGRESS with a stale lease, which is genuinely ambiguous — the platform cannot know whether the effect happened.
Resolution is to retry with the same key and let the downstream deduplicate, which is why the key is on the wire rather than only in the platform's own store.
Handlers declare an idempotency mode: natural (the operation is inherently repeatable), keyed (the downstream honours the key), or unsafe. An unsafe handler is marked non-retryable and dead-letters on first failure rather than risking a second effect.
Risks
Every unsafe handler converts a transient failure into operator work. The count of unsafe handlers is a metric worth watching, because it is the platform's real reliability ceiling.
The idempotency record TTL of 7 days must exceed the longest possible retry window. A workflow with a long paused branch could in principle outlive it, which is a validation rule rather than a hope.
Duplicate suppression at the message layer covers 10 minutes only. Beyond that the handler and downstream carry the entire burden.
