Retry

Retry

Type: retry  ·  Package: Core Activities v1.0.8

Runs a block of activities and, if it fails, tries again up to a maximum number of times, with an optional wait between attempts. It is ideal for actions that fail intermittently and usually work on the second or third attempt: a slow website, an unstable network, a system that is slow to respond.

How it works

1. Runs the body block.
2. If it succeeds, it ends and the flow continues.
3. If it fails, it logs a warning with the reason (Attempt 1 of 3 failed: …), waits delay milliseconds (if you set it) and tries again.
4. Repeats until attempts are used up. If all fail, the activity fails with a message that includes the last error (which stops the execution, unless it is inside a Try / Catch).

Cases that are not retried:

• A business error (Throw with errorType = "BusinessRuleException", also when it comes from an invoked playbook): retrying does not fix the data, so Retry fails right away with that error and keeps its type.
• An execution terminated from outside: it stops with no more attempts.
• A Break or Continue inside the body: they are not errors and go through to the loop that contains the Retry.

Required parameters

Parameter	Type	Default	Description
attempts	int	—	Maximum number of attempts, including the first one. E.g. 3 = one attempt + 2 retries. A value below 1 counts as 1.

Optional parameters

Parameter	Type	Default	Description
delay	int	0	Milliseconds to wait between attempts (not before the first nor after the last). 0 = no wait.

Sub-flows

body required

The activities to run and, if they fail, retry.

Output

This activity does not return a value. Whatever the body activities produce (their Output) keeps the values from the attempt that succeeded.

Example

Retry a web action up to 3 times, waiting 2 seconds between attempts:

Retry   attempts = 3   delay = 2000
 └─ body:
      Page Navigate   page = page   url = "https://portal.example.com"
      Page Click      page = page   selector = "#login"

If the first attempt fails (the page didn’t load), it waits 2 s and retries; if the second fails, it waits and retries once more. If the third also fails, the activity fails with the last error.

Each attempt re-runs the WHOLE body

If the block has several activities and fails on the last one, the retry runs all of them again from the start. Keep in the body only the actions that make sense to repeat together (ideally idempotent — repeating them does not cause duplicate effects).

Retry vs Delay vs Try/Catch

• Delay: fixed wait, no retry. Fragile on its own.
• Retry: retries an unstable action. The best option for transient failures.
• Try / Catch: handles the error with a plan B when retrying is not enough.

Combine them: put a Retry inside the try of a Try/Catch to retry first and handle the final failure afterwards.

A timeout inside the body (a service that does not answer in time, an activity’s timeout) is an error like any other and is retried (TimeoutException). Terminating the execution, instead, stops the retries right away. Since version 1.2.29.

Common errors

Message	Cause and fix
All … attempts failed. Last error: …	Every attempt failed. The end of the message is the last attempt’s error: fix that cause, raise attempts or delay if the system needs more time, or handle the failure with a Try / Catch. In a catch error variable, .Message and .Type are those of the last error, not this summary.
Attempt … failed with a business rule error; not retrying: …	Log warning: a business error stopped the retries. The activity fails with the original message; handle it in the catch by comparing error.Type == "BusinessRuleException".
'body' must be an array of activities.	The Retry has no body lane. Add the activities to retry inside it.

Related activities

• Try / Catch — handle the error if every attempt fails.
• Throw — throw a business error that Retry does not retry.
• Delay — fixed wait (Retry already includes delay between attempts).