Retry step

Set steps to retry by opening the Execution Options menu and selecting an option from the Retry after option.

1. After step failure retries the step if the step's call or action returns a failure status.
2. Retry on condition retries the step until the specified condition is met, or until the amount of calls maxes out. At the moment, one may specify one condition to be met per step. This logic is similar to loops without needing to build a full loop, if, and break condition.

Seconds delayed & maximum retries

• If your initial delay is set to one second, the exponential backoff will run until the delay reaches one minute, and then the delay will remain at one minute.
• If your initial delay is set to one minute, the exponential backoff will run until the delay reaches one hour, and then the delay will remain at one hour.
• If your initial delay is any higher than one hour (two hours, one day, etc.) then there will be no exponential backoff added.
• As long as the cumulative time of delays, with a 25% exponential backoff, does not exceed 31 days, the step will continue to retry for the duration.
  • If the amount of seconds delayed or maximum retries cumilitaively equal to multiple days, the workflow executions quota will not become clogged because a workflow with steps between retries is considered in the wait status.

* It is important to note that there is no notification that the step is being retried - the workflow may be held in wait status for a maximum of 31 days (if you have set it to the maximum) before the workflow will move forward.

Editing & factoring

• The delays and retries may be modified from within the YAML. The lines to be edited will look as follows:

retry:
 type: 1
 delay: 10
 max_retries: 30

By default, there is an exponential backoff factor 1.25 wich will retry the step with increasing wait times (e.g.: 1 second -> 2 seconds -> 4 seconds). It is highly recommended to retain the exponential backoff when retrying API calls so as to avoid retry collisions and avoid overwhelming systems. However if you want to remove the backoff factor in order to utilize the retry condition as a self-contained loop, you can adjust the factor to 1 by adding a "factor" line in the step's YAML to look as follows:

retry:
factor: 1

Step failure

• If all retry attempts have been completed and the step is still failing or the condition has not been met, your selection for Ignore failure will determine if the workflow fails or continues forward.

Parallel execution

• Steps running in parallel will not move forward until all steps are finished retrying - if one step is continuously failing or not meeting its condition, all the parallel executions will wait to move forward until the attempts finish.