Stay organized with collections Save and categorize content based on your preferences.

See the supported connectors for Application Integration.

Error handling strategies

This page describes the various supported error handling strategies. Errors can occur during the execution of a task and the type of errors can be either permanent or temporary.

Permanent errors

Permanent errors cause the task to fail permanently. Even if you rerun the integration, the task fails. Examples of permanent errors are:

  • Authentication failures
  • Data validation errors

Temporary errors

Temporary errors cause the task to fail temporarily. If you rerun the integration, it is possible for the task to run successfully.

An example of a temporary error is the HTTP 503 Service Unavailable error. This error can occur if the task is dependent on the response from an external application, and the external application is unavailable or overloaded.

Types of error handling strategies

The error handling strategy for a task specifies the action to take if the task fails due to a temporary error. You can specify any of the following error handling strategies for a task:

  • Fatal: Stops the execution of the entire integration and marks the execution status as Failed.
  • Ignore: Ignores the failure of the task. The integration continues to run the next tasks assuming the failed task has Succeeded.
  • None: Stops execution of the task and marks the integration status as Failed. If an alternate path to the final task (leaf task) exists, tasks in the alternate path are run. If all tasks in the alternate path run successfully, marks the integration status as Succeeded.
  • Restart integration with backoff: Runs the entire integration from the first task. However, the task might fail again. To avoid repeat failure, specify the time interval between restarts in the Retry interval (in seconds) field and the number of permitted restart attempts in the Maximum retry count field.
  • Retry task with exponential backoff: Runs the integration from the failed task. If the task fails during a retry, the time interval between each retry attempt increases by the power of 2.

    For example, suppose the specified retry interval is 3 seconds, the first retry occurs after 3 seconds. The second retry occurs after 9 seconds, the third retry after 81 seconds, and so on. The process continues until the maximum number of retries is reached or the task succeeds, whichever is earlier.

  • Retry task with fixed interval: Runs the integration from the failed task. If the task fails during a retry, the time interval between each retry attempt remains constant.

    For example, suppose the specified retry interval is 3 seconds, retries occur every 3 seconds. The process continues until the maximum number of retries is reached or the task succeeds, whichever is earlier.

  • Retry task with linear backoff: Runs the integration from the failed task. If the task fails during a retry, the time interval between each retry attempt increases linearly.

    For example, suppose the specified retry interval is 3 seconds, the first retry occurs after 3 seconds. The second retry occurs after 6 seconds, the third retry after 9 seconds, and so on. The process continues until the maximum number of retries is reached or the task succeeds, whichever is earlier.

Note: Error handling strategies are not available for permanent errors.

Synchronous and asynchronous error handling

You can run your integrations in either synchronous or asynchronous modes, with options for retry on failure of the integration in either mode.

In synchronous mode, the execution result of the integration is available soon after the integration runs. Synchronous mode is helpful in scenarios where you want the execution result immediately after the integration runs.

Asynchronous executions use the fire and forget model. Asynchronous mode is helpful in scenarios where integrations can take a long time to run, or the execution result is not required immediately after the integration runs.

You can specify different error handling strategies for each execution mode (synchronous and asynchronous):

  • For synchronous executions, specify the error handling strategy in the When integration is run synchronously section of the task's Retry on Failure configuration.
  • For asynchronous executions, specify the error handling strategy in the When integration is run asynchronously section of the task's Retry on Failure configuration.