Introduction to errors and warnings

When an automation does not behave as expected,  reports the issue as either a warning or an error, preventing your scenario from running. Errors and warnings can occur due to several reasons including connection issues, invalid mapping, API errors, etc.

Errors indicate that your  encountered an unexpected event that was not handled by an . As a result, you should review the  to identify and resolve the issue.

A module will return an error when it receives invalid data from previous modules or from the app itself. When you open your  in the  editor,  highlights the module that produced the error with an alert sign. To view the error type, click the alert sign displayed above the module.

When you click the caution sign, you can check the bundle that caused the error in the module:

When a module outputs an error,  stops the current  run and initiates a rollback. During this phase,  attempts to revert any changes made before the error occurred, restoring the system to the state it was in prior to the  execution.

If a  encounters errors across multiple consecutive runs,  automatically disables the 's schedule. Disabling the  prevents repeated failed executions, allowing you time to investigate and resolve the issue while avoiding unnecessary consumption of operations.

The following are the most common reasons that can cause a module to return an error:

 classifies errors based on two primary factors, their origin and their underlying cause.

Example: A ConnectionError typically occurs when a third-party service is having an issue or incident. In this case, the origin is the external server, and the cause is the inability to establish a connection.

When errors are not handled by any error handler,  sends you an email notification:

 also sends out a notification when your  gets disabled because of repeated errors.

You can learn more about  email notifications and their settings here.

Warnings alert you that there was an issue during the  run, but not as serious as an error. Also,  can have a Warning status if errors are successfully handled by your configured error handlers or .

When a module in a  returns a warning, your  keeps running and stays enabled. A warning doesn't disable the scheduling of your  and warnings don't count into the number of consecutive errors. But it's a good idea to check the scenario execution historyscenario execution history to view the cause of the warning.

A warning can also be the result of handling an error with the Retry error handler. With the warning  informs you that the Retry error handler created an incomplete executionincomplete execution of your .

When a module returns a warning,  highlights the module with a yellow caution sign. To check the warning, click the caution sign displayed above the module.

When you use , you will see a warning when the error handler activates. In the example above, the Retry error handler handled the BundleValidationError. The error handler activation turned the original error into a warning.

The following are the most common  that cause a module to return a warning: