Retry Rules
Three objects decide what happens to a failure: the error definition that names it, the fallout definition that matches it, and the retry configuration the definition chooses. This page follows one failure through them, then covers the manual actions available when automatic retries are spent. The screens where you see fallouts are documented under Monitoring; this page is about the rules they follow.
How a failure is resolved
- An execution fails at a step, and Engage records a fallout carrying the service, the step, and an error code.
- Engage looks for an active fallout definition that matches. An application-scoped definition matches on service, step, and error; an organisation-scoped one matches on error code alone. See Fallout definitions.
- The matched definition's retry policy runs. Fixed Interval waits Retry After (Sec) before every attempt; Exponential Back Off multiplies the wait by Backoff Multiplier each time, never exceeding Max Delay (Sec). Attempts run only within the policy's active hours and days, if any are set, and only if the error is among its Eligible Error Types or that list is empty. See Retry configuration.
- If an attempt succeeds, the fallout is done. If Max Retries attempts have failed, the fallout is exhausted: its row carries an Exhausted tag, and it waits for an operator.
A failure with no matching definition skips step 3 and waits for an operator straight away. This is where Define Fallout on the fallout's details is useful: it opens the definition form pre-filled with that failure's service, step, and error.
Statuses
A fallout's Status column shows its lifecycle status. The three that mean automatic
handling is over are RETRIED_AND_FAILED, MANUALLY_RETRIED_AND_FAILED, and
DISCARDED; a fallout in any of them, or one whose retry count has reached the policy's
maximum, shows the Exhausted tag. Only a fallout in the MANUAL state accepts the
operator actions below, so an exhausted fallout that is not yet manual is still being
handled by Engage.
Manual retry actions
Once a fallout is in the MANUAL state an operator can retry it, in four ways, or mark
it resolved. Those actions, the bulk Retry Selected control, and the fallout's
details and trace belong to the fallout list screens and are documented in
Global Fallout. Two rules from this side apply
when they run:
- A manual Retry re-executes the failed step with the fallout's current payload. If the matching fallout definition has Allow data modify on, the payload can be edited before the retry and the edited version is what runs.
- Retry From Workflow offers only the retry workflows the application's manifest lists under Retry Workflows in Studio. If that list is empty, the option reports No published retry workflows found for this fallout; add one in the manifest and publish. See Prepare an Application for Engage.
Define Fallout, on the same details, creates a fallout definition for this failure so future occurrences are retried automatically. See Fallout definitions.
Retry channel
Every fallout definition shows a Retry Channel of HTTP, and the field cannot be
changed. Retries call back into the application over HTTP; there is no queue-based
channel to configure in the current release.
When it does not work
| Symptom | Cause | What to do |
|---|---|---|
| No published retry workflows found for this fallout | The application's manifest defines no retry workflows, or none is published | Add one under Retry Workflows in the Studio manifest and publish; see Prepare an Application for Engage |
| A failure is never retried automatically | No active fallout definition matches it, or the matched policy is inactive or outside its active hours | Select Define Fallout on the failure, and check the policy under Retry Config |