Comment on page

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
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

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	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

Automation - Previous

Flow Debugger

Run Flows again

Last modified 7mo ago