Set steps to retry by opening the Execution Options menu and selecting an option from the Retry after option. This is important if you are conducting calls to servers that may get overwhelmed or have limited calls available. Both retry options allow you to select the number of retry attempts and the number of seconds to wait between recalls.
After step failure, retry the step if the step's call or action returns a failure status.
Retry on condition retries the step if the specified condition is met or the number of calls maxes out. At the moment, one may specify one condition to be met per step. This logic is similar to loops without building 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.), no exponential backoff will be added.
If 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 number of seconds delayed or maximum retries cumulatively equal to multiple days, the workflow executions quota will not become clogged because a workflow with steps between retries is considered in the On hold 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 of 1.25, which will retry the step with increasing wait times (e.g., 1 second -> 2 seconds -> 4 seconds). It is highly recommended that the exponential backoff be retained when retrying API calls to avoid retry collisions and overwhelming systems. However, if you want to remove the backoff factor 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 fails or the condition was not met, your selection for Ignore failure will determine if the workflow fails or continues.
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 until the attempts finish.