Retry

Retry is an orchestration component that causes the pipeline to repeatedly try to run a specific component until either that component’s execution succeeds or a maximum number of retry attempts is reached. You can configure how many times the component retries, and the delay between each retry.

The Retry component is attached to a single specific component that you want to retry. The mechanism for attaching and detaching a Retry component on the canvas is the same as that used for iterator components. Read Iterator components for details.

During the interval between retries, nothing is shown in the task panel, and it may appear that although the pipeline run hasn’t completed yet, nothing is running. Once the current wait time is reached, the task is added to the run for its next attempt, and the pipeline continues.

---

Properties

Name · string · required

A human-readable name for the component.

Number of retries · integer · required

The maximum number of times to retry the connected component. The total number of times the component could be run is one (the original run) plus the number of retries. The first time the component succeeds, the success link is followed and there are no further retries. If the final retry fails, the failure link is followed.

The default number of retries is 1.

Retry delay · drop-down · required

Certain kinds of transient failures may benefit from a delay before retrying. The Retry delay parameter provides strategies for retrying quickly or slowly, with the ability to leave longer and longer pauses between attempts (known as backoff).

• Custom: Specify a custom delay value of hours, minutes, or seconds.
• Long delay: Waits approximately 15 seconds between retries.
• Long delay with backoff: Waits longer between each failure, at approximately 15, 30, 60, 120, 240… seconds.
• Retry immediately: Immediately retries up to the maximum number of retries. This is the default setting.
• Short delay: Waits approximately 2 seconds between retries.
• Short delay with backoff: Waits longer between each failure, at approximately 1, 2, 5, 10, 20, 40… seconds.

Specifying a delay with backoff can result in extremely long overall delays, as the delays between each subsequent retry grow exponentially. For example, a Long delay with backoff would require approximately 2.1 hours for 10 retries, growing to approximately 3 months for 20 retries. This all counts toward billable task execution time. To guard against this, you should set the Max delay property to a realistic value.

Retry interval · integer · required

An integer value of the unit specified below. The default value is 1. An error occurs if the value is below 0 or above 3600. An error also occurs if the value is not an integer. This property is only available when Retry delay is set to Custom.

Retry time unit · drop-down · required

The time unit used with the value in Retry interval. Select Hour, Minute, or Second. This property is only available when Retry delay is set to Custom.

Max delay · integer

The overall maximum delay the retry component allows, in seconds, minutes, or hours as specified in the Max delay time unit property. This is to prevent a high value of Number of retries leading to an unacceptably long overall delay. The default is 32 minutes.

This property only applies when Retry delay is either Long delay with backoff or Short delay with backoff.

Max delay time unit · drop-down

The time unit used with the value in Max delay. Select Hour, Minute, or Second. The default is Minute.

This property only applies when Retry delay is either Long delay with backoff or Short delay with backoff.