Default Retrying
By default, steps retry up to 3 times on arbitrary errors. You can customize the number of retries by adding amaxRetries property to the step function.
When a retried step performs external side effects (payments, emails, API writes), ensure those calls are idempotent to avoid duplicate side effects. See Idempotency for more information.
Intentional Errors
When your step needs to intentionally throw an error and skip retrying, simply throw aFatalError.
Customize Retry Behavior
When you need to customize the delay on a retry, useRetryableError and set the retryAfter property.
Advanced Example
This final example combines everything we’ve learned, along withgetStepMetadata.
Setting
maxRetries = 0 means the step will run once but will not be retried on failure. The default is maxRetries = 3, meaning the step can run up to 4 times total (1 initial attempt + 3 retries).Rolling Back Failed Steps
When a workflow fails partway through, it can leave the system in an inconsistent state. A common pattern to address this is “rollbacks”: for each successful step, record a corresponding rollback action that can undo it. If a later step fails, run the rollbacks in reverse order to roll back. Key guidelines:- Make rollbacks steps as well, so they are durable and benefit from retries.
- Ensure rollbacks are idempotent; they may run more than once.
- Only enqueue a compensation after its forward step succeeds.