Activities and Workflows can fail for a number of expected and unexpected reasons. In most failure cases, we want to retry the failed Activity or child Workflow or even the parent Workflow. By default, Temporal retries Activities, but not Workflows. To change the default behavior, a custom retry policy can be provided.
To change the default behavior, a custom retry policy can be provided.
A retry policy is defined as a
To enable or customize retries, provide a custom retry policy as part of
If an Activity heartbeat its progress before it failed, the retry attempt will have access to the progress information, so that the Activity implementation could resume from the failed step. Here's an example of how this can be implemented:
To enable retries for a Workflow, you need to provide a retry policy via
ChildWorkflowOptions for child Workflows or
WorkflowOptions for top-level Workflows.
There are some subtle nuances to how Workflow's history events are recorded when a
RetryOptions is used.
For an Activity with a
ActivityTaskScheduledEventwill have extended
ActivityTaskStartedEventwill not show up in history until the Activity is completed or failed with no more retry. This is to avoid filling the history with noise records of intermittent failures and retries. For Activities being retried,
DescribeWorkflowExecutionwill return a
For a Workflow with
- If a Workflow fails and a retry policy is configured for it, the Workflow execution will be closed with a
ContinueAsNewevent. This event will have the
ContinueAsNewInitiatorfield set to
RetryOptionsand the new
RunIdfor the next retry attempt.
- The new attempt will be created immediately. But the first decision task won't be scheduled until the backoff duration.
That duration is recorded as the
firstDecisionTaskBackoffSecondsfield of the new run's