Retry

Send the run back to try a part of the workflow again, a set number of times, then give up by its fallback.

In both appsWarpX BrowserWarpX Phone

Retry repeats a whole stretch of a workflow when it fails, such as a login that sometimes times out. It does not detect failures itself: you connect a failure into it, and its first output back to the block where the attempt starts. Each time the run reaches it, it sends the run back, until the tries are used up; then it leaves by its fallback output, your give-up path.

The Retry block's settings, filled in as in the example below.

Settings

Description: A note shown on the block in the canvas.
ExampleRetry login
Tries again: How many times to send the run back. 3 means up to four attempts in all: the first one and three more.
Example3
Wait between tries (seconds): A pause before each try again, so a slow site or a busy proxy has time to recover.
Example5
Count the tries separately for each loop item: Inside a loop, every item gets all its tries: the third account in a list starts fresh even when the second used them all up. Off, the tries are shared by the whole run.
ExampleChecked

Every block also has the shared block settings — a description, Disable block and what to do on an error. Fields that take text accept data from earlier blocks.

What it hands on

Two outputs. The first (top) is taken while tries are left, after the pause, and should lead back to where the attempt starts; it hands on how many times it has sent the run back, 1 the first time, as {{prevBlockData}}. The fallback (bottom) is taken once the tries are used up, logged as Gave up after 4 tries. With nothing connected to the fallback, the block fails with that message instead.

Example: Retry a flaky login three times, then mark the account failed

Loop data
Open URL
Forms
Click element
Wait for
Retry
Insert data
Loop breakpoint

Where Retry sits in the example workflow.

Inside a Loop data block over your accounts, add an Open URL block with https://app.example.com/login. This is where each attempt starts.
Add Forms blocks for the email and password and a Click element block on button[type=submit].
Add a Wait for block: Wait until The address matches, Address contains /home, Give up after (ms) 20000. Its top output goes on to the rest of the workflow for a signed-in account.
Add a Retry block with Tries again 3, Wait between tries (seconds) 5 and Count the tries separately for each loop item ticked.
Connect the Wait for block's fallback output (the failure) to the Retry block's input.
Connect the Retry block's first output back to the input of the Open URL block from step 1. That line is the loop that tries again.
Connect the Retry block's fallback output to an Insert data block that writes login failed to a status column, then to the Loop breakpoint, so the run moves on to the next account.

Good to know

Anything that marks a failure can lead into Retry: the fallback of Wait for, the bottom output of Element exists, the Fallback of Conditions, or the error output any block gets when you set On error to Execute fallback in its settings. Several of them can lead into the same Retry, and they share its count.
Point the first output at the start of the attempt, not only at the block that failed. Going back to the Open URL above means each try starts from a fresh login page rather than a half-filled form.
The built-in Retry action in a block's On error settings runs that one block again. Use the Retry block when a whole stretch has to run again.
The count is kept for the whole run and only starts over once the block gives up. A success does not reset it: outside a loop, or with the box unticked, a later failure that reaches the same Retry gets only the tries that are left.
A Tries again of 0 gives up at once, straight to the fallback.

Retry

Settings

What it hands on

Example: Retry a flaky login three times, then mark the account failed

Good to know

See also