Automatic Retrying

Automatic retrying of failed flows due to third party timeouts, downtimes, or rate limits

Introduction

Locoia has an automatic retry logic for failed flows to handle third party timeouts, downtimes, rate limits, etc.. This makes it very convenient that if something goes wrong along the way your data and any temporarily generated data is stored and can be reused in order to continue exactly where the Flow Run was unintentionally stopped.

Automatic retrying is turned on by default, but can be turned off on a per Flow basis in the Flow's settings.

Possible reasons for failure

• Flow is setup or built incorrectly

• Flow is built to process data in a certain way, but there may be data inconsistencies from time to time, as usual in data handling.

• Systems or APIs that flows interact with may be down or temporarily out of service.

• Systems or APIs may have rate limits allowing only a certain number of API calls per time unit, e.g. 100 per minute is often used.

How flow failure is handled - smart retries

There are three different groups of errors, which have different retry logics:

Groups	Retryable, with a long delay	Retryable, with a short delay	Non-retryable
Applies to all Connectors and the following Helpers	Rest Helper	Rest Helper FTP Helper SQL Connector	All Helpers
Applicable errors (Checks from left to right, if any of the cases are applicable ['OR' check])	HTTP status codes 429, 503 Retry-After or X-RateLimit-Reset header is specified (except for 2xx status codes)	HTTP status is 5xx (except for 503) DNS resolution failed Network connection was abruptly closed Generic network error happened	HTTP status is 4xx (except for 429) User input contains Jinja syntax errors + All errors that didn’t fall into the first two groups
Retrying behavior	Retry once based on the Retry-After or X-RateLimit-Reset header or, if not set, after 3 minutes. If the Retry-After header specifies a value higher than 10 minutes, retrying will not take place at all.	Retry after 1 second, regardless of Flow status and custom error handling settings.	No retrying
Visibility in Flow Debugger while retrying	Flow Run and Flow Run Step have status retrying	Flow Run and Flow Run Step have status running	N/A

For all retry groups an error email will be sent once the Flow Run's status changed to error (i.e. once retrying has taken place).

Error Handling Flows will be triggered for each error Flow Run Step, even if it is being retried successfully.

When the Flow's data retention is set to 0 and an error occurs in one of the steps that falls into the first group, this step's contents will be temporarily stored and displayed in the Flow Debugger in order to make retrying possible.

In case you don't want this to happen, automatic retrying has to be disabled for the Flow