Skip to main content
By default, errors thrown inside steps are retried. Additionally, Workflow DevKit provides two new types of errors you can use to customize retries.

Default Retrying

By default, steps retry up to 3 times on arbitrary errors. You can customize the number of retries by adding a maxRetries property to the step function.
Steps get enqueued immediately after a failure. Read on to see how this can be customized.
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 a FatalError.

Customize Retry Behavior

When you need to customize the delay on a retry, use RetryableError and set the retryAfter property.

Advanced Example

This final example combines everything we’ve learned, along with getStepMetadata.
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.