States can encounter runtime errors for various reasons:

  • Transient errors such as network outages and congestions
  • JSON path resolution errors

Map state and ZIS built-in actions support error handling fallback through the Catch field. Example:

"Catch": [  {    "ErrorEquals": [      "States.ALL"    ],    "Next": "AnotherState"  }]

Currently, the only supported error state is States.ALL. When an error occurs, the workflow will transition to the state named in the Next field.

Retry logic

A running Flow will retry if it:

During a retry, the entire Flow will run again from the beginning. Ensure your use case and Flow logic accounts for this.

The interval between retries varies based on the retry scenario. Regardless, ZIS will only attempt to run a Flow three times: the initial attempt and up to two retry attempts.

Retry on a fail state

If a Flow ends on a fail state, ZIS will retry the Flow after 30 seconds, then again after a further 60 seconds.

Retry after rate limiting

A 429 HTTP status code means "too many requests." When an API returns an error with this code, it means an account is sending too many requests to the API too quickly. This is called rate limiting.

Some APIs include a Retry-After header in responses with a 429 error. This header specifies a period of time you should wait before retrying the API call.

If an HTTP-based action in a Flow receives a 429 error, the Flow will retry based on the Retry-After header's value.

Retry-After header value Flow Retry behavior
Less than 120s (120 seconds) Retry after the Retry-After interval
120s or greater Retry after 120 seconds
No Retry-After header Retry after 30 seconds, then again after a further 60 seconds

Retry after a server error

A 500 HTTP status code means something has gone wrong with the API's web server.

If an HTTP-based action in a Flow receives a 500 error, the Flow will retry after 30 seconds, then again after a further 60 seconds.

Manual retries

To manually retry a Flow for other types of errors, use a Catch block in your Action to catch the error, followed by a Choice state to check for a specific error code. For example:

{  "StartAt": "Zendesk.GetTicket",  "States": {    "Zendesk.DoSomething": {      "Type": "Action",      "ActionName": "zis:YOUR_INTEGRATION_NAME:action:zendesk.YOUR_ACTION_NAME",      "Parameters": {        "ticketId.$": "{{$.input.ticket.id}}",        "accessToken.$": "$.connections.YOUR_TARGET_SYSTEM.access_token"      },      "Catch": [        {          "Comment": "ZIS only supports catching all error types, i.e. States.ALL",          "ErrorEquals": [            "States.ALL"          ],          "Next": "CheckErrorType"        }      ],      "ResultPath": "$.do_something_result",      "End": true    },    "CheckErrorType": {      "Comment": "Checks whether the error caught is a 404",      "Type": "Choice",      "Choices": [        {          "Variable": "$.Cause",          "StringEquals": "external action failed due to status code: 404",          "Next": "log.errorCaught.404"        }      ],      "Default": "log.errorCaught.other"    },    "log.errorCaught.404": {      "Comment": "Use this branch to handle 404 error"      "Type": "Succeed",      "Message": "I caught a 404 error"    },    "log.errorCaught.other": {      "Comment": "Use this branch to handle other errors"      "Type": "Succeed",      "Message": "I caught a non-404 error"    }  }}