retryStrategy

Defines the strategy of dealing with failed tasks and subflows before they result in a failure of the entire flow.

Schema

YAML

timeout: float | None
limit: int | None

Properties

Property	Type	Description
timeout	float | None	Maximum time in seconds that a task is run before it is considered failed.
limit	int | None	Number of attempted retries before a task is considered failed.

Examples

Retrying a task before failing the entire flow

Under normal circumstances, a failure of a task within a flow results in a failure of the flow and its immediate termination. However, due to the quantum nature of the experiments run within a flow, you may want to retry a task a certain number of times before aborting the flow. For instance, you might say that a task is considered successful if it can be finished in at most 3 retries after an initial failure (for a total of 4 attempts). In this case, you can simply use specify the retryStrategy for the task as:

retry:
  limit: 3

In this case, a task must fail three times in a row in order to stop the flow.

Failing long-running tasks

When you run an experiment on a QPU, you expect it to finish in a reasonable time. If an experiment runs longer than expected, it usually signifies an abnormal situation, such as an error in the experiment code or a hardware malfunction. A long-running task can block other people from accessing the QPU.

To avoid a scenario in which a task takes too long in a flow, you can use the timeout property of the retryStrategy object in a task:

retry:
  timeout: 30

The code above will cause a task to be declared as failed after 30 seconds. Sometimes, however, it is possible to just rerun the experiment to get the results required. In this case, you can combine both the timeout and limit properties. For instance, if you want the task to be stopped after 30 seconds, but retried twice (for a total of maximum 3 runs) before a flow fails, you can specify as follows:

retry:
  limit: 2
  timeout: 30