Preview

This product or feature is covered by the Pre-GA Offerings Terms of the Google Cloud Terms of Service. Pre-GA products and features might have limited support, and changes to pre-GA products and features might not be compatible with other pre-GA versions. For more information, see the launch stage descriptions.

See the supported connectors for Application Integration.

Error handling strategies

This page describes the types of errors that can occur during the execution of a task, and the various supported error handling strategies.

Errors can be either permanent or temporary:

Permanent errors

All client-side errors are considered as permanent errors, for example, authentication failures and data validation errors. Permanent errors cause permanent task failures.

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

Temporary errors

All server-side errors are considered as temporary errors, for example, HTTP 503 Service Unavailable error. Temporary errors cause temporary task failures, you can specify any of the supported error handling stratergies to handle a temporary errors in your integration.

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.

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.