Skip to main content
The workflow engine provides automatic retries, checkpointing for recovery, and patterns for ensuring exactly-once execution of side effects.

Retries

Step-level retries

Service steps retry automatically on failure with exponential backoff:

forEach item retries

When using forEach, retries apply per item:
With onItemError: "skip", failed items are logged and skipped after exhausting retries. With "fail" (default), the first item failure after retries stops the entire step.

Pagination retries

Each page request can retry independently:

Checkpointing

The workflow engine checkpoints progress at multiple levels. If a worker crashes or the job is interrupted, it resumes from where it left off:
  • Step-level — completed steps are not re-executed
  • Page-level — paginated steps resume after the last fully completed page
  • Item-level — forEach steps skip already-completed items
This means long-running workflows are resilient to transient failures — a paginated fetch through thousands of pages or a forEach over hundreds of items will pick up where it stopped, not start over.

Idempotency

Prevent duplicate active jobs for the same logical operation using an idempotency key:
If a job with the same idempotencyKey is already active (pending or running), the submission is rejected. This is especially useful for manual triggers and webhook-initiated workflows.

Exactly-once side effects

For operations with real-world consequences (payments, notifications), ensure they execute exactly once even across retries.

Native idempotency keys

If the target API supports idempotency keys, pass a deterministic key derived from the data:

preExecute checks

For APIs without native idempotency, use preExecute to check whether the operation has already been performed:
If preExecute finds an existing result matching the condition, the main operation is skipped and the mapped values are used as the step output instead.