Set the number of retries
To rerun your workflow when an exception is raised, set theretries parameter to an integer.
Retry nested flows
When a parent flow retries a direct call to a nested flow, Prefect reuses the child’s completed result if it was persisted. Setpersist_result=True on the child flow to enable result persistence.
If the child failed or completed without a persisted result, the parent retry creates a new child flow run.
The new run has its own retry budget, while the previous run keeps its state and history.
Because the child has a new flow-run ID, task caches that include the flow-run ID do not carry over from the previous child run.
Wait between retries
To add a wait between retries, pass a value to theretry_delay_seconds parameter.
Retry parts of a workflow
You can configure retries for individual tasks in a workflow to limit the scope of a retry.Retry with configurable delay
A task’s retry delays can also be defined as a list of integers for different delays between retries.exponential_backoff utility to generate a list of retry delays that correspond to an exponential backoff retry strategy.
Retry with a custom condition
Whether or not a task should be retried can be determined dynamically by passing a callable to theretry_condition_fn parameter.
retry_condition_fn returns True, the task will be retried. Otherwise, the task will exit with an exception.
Add jitter to retry delays
To add a random amount of time to retry delays, pass a value to theretry_jitter_factor parameter.
Configure task retry behavior globally
You can set the default retries and retry delays for all tasks via Prefect’s settings. The default values can be overridden on a per-task basis via theretries and retry_delay_seconds parameters.