Setting Up Retry Steps
Execution packages have two ways of handling errors: fail and retry. The default is to fail when an error is encountered, which protects the integrity of data in the environment. However, data sources may be periodically locked by updates, backups, or other processes. When a load collides with one of these processes, the failure does not represent a problem that needs fixing — the desired behaviour is simply to wait and try again. Retry steps provide this functionality.
Retry options
The retry step option has three configurable values:
- Retry delay in minutes: The time the package waits between an execution failure and the next retry attempt.
- Retries: The total number of retries the package will attempt across all steps.
- Retries per Step: The number of retry attempts allowed for any single execution step. An execution step is a basic execution task such as running a pre-step, post-step, or data cleansing script.
How Retries and Retries per Step interact
The Retries value can effectively override Retries per Step — running down either counter causes the package to fail.
For example, if Retries per Step is set to 3 and Retries is set to 1: the package retries once when a step fails. If the step fails again, the package checks the remaining step retries (2 remaining) and the remaining package retries (0 remaining), and fails because the package-level counter has been exhausted.
For most packages, set Retries to the number of steps that may fail multiplied by the number of retries per step.
Example: to allow up to four steps to fail, with each step retried twice — set Retries per Step to 2 and Retries to 2 × 4 = 8.
Example: to allow one step to be retried up to three times — set Retries per Step to 3 and Retries to 3 × 1 = 3. Note that this configuration could also result in three different steps each being retried once — this is a known limitation of the current retry implementation.