Skip to main content

Execution flow part II

Retrying actions​

Actions that depend on network connectivity or 3rd party services might fail for multiple reasons:

  • temporal network issues (DNS resolution failure, timeouts, micro-cuts)
  • temporal endpoint issues (API limits, temporal service unavailability)

Aborting the execution of an entire blueprint just because there was a temporal issue in one particular action is not acceptable, which is why there are retry policies in place.

Any time one of the following HTTP errors occurs, the action will be retried 5 times, with a backoff of 10s + Ns (N being the retry count).

  • 429 - Too Many Requests
  • 502 - Bad Gateway
  • 503 - Service Unavailable
  • 504 - Timeout

Additionally, retries will be triggered when:

  • there is a network issue
  • there is a DNS resolution issue

Last, but not least important, retries will be triggered on specific errors returned by specific providers (a list of the specific errors can be found in the documentation of each provider). For example, AWS might return RequestsLimitExceeded or InsufficientInstanceCapacity, which are examples of requests that can be handled and retried.

Not retrying actions​

Of course, there might always be a case in which you won't need actions to be retried. Retries can be disabled for each individual action. Go to the Settings » Advanced and switch on the Show advanced action settings option. From this point on, you'll be able to see the advanced settings of each action. Among the advanced options there is the Max retries option, which you can set to 0 in order to disable the retries handling for a particular action.