Retries, idempotency & replay

Retries

Each step has a retry policy (max attempts, exponential or fixed backoff with jitter, retryable error classes). Validation and 4xx errors fail permanently. 429 honours Retry-After.

Non-idempotent actions

Steps that can create duplicates (sending a message, POSTing to an API without an idempotency key) are not retried after an ambiguous failure such as a timeout. They move to requires attention so a person decides.

Idempotency keys

Every step gets a stable key <root execution>:<step>, sent as the Idempotency-Key header on HTTP steps and to providers that support it. Replays reuse the same keys.

Replay

From failure (default) copies successful step outputs and re-runs only what failed. Full re-runs everything and requires explicit confirmation. Demo executions cannot be replayed.

Dead letters

Queue messages that exhaust delivery attempts are stored and the execution is marked requires attention.