Overview of error handling
{}When you are creating , you might encounter unexpected data or unexpected circumstances. notifies you about these events with an error to keep your reliable and functioning.
You can use error handlers to deal with errors or unexpected events in your . An error handler connects to a module with the error handling route. When the module outputs an error, the error handling route activates and runs the error handler.
If an error occurs that is handled by an error handler, keeps scheduling your because can assume that you anticipated the situation and prepared for it.
There are 5 error handlers in :
An error handler is always at the end of the error handling route. The error handling route has a transparent filling:
When an error handler activates, it doesn't consume operations. doesn't bill you for handling unexpected events in your .
The error handling route doesn't have to have an error handler. For example, in the error handling route, there can be only a Slack > Create a message module to send you a Slack notification when an error happens.
If no module outputs an error in the error handling route, ignores the error. That means that the two error handling routes on the pictures work the same:
If a module in the error handling route outputs an error, the run ends with an error.
When you are building or checking your in the editor, highlights the module that caused the error with a warning sign in front of the module name and in the list of bundles.
When you click the bubble with the warning sign, you can check the bundle that caused the error in the module:
- The red fields are quick action buttons. You can click the buttons to connect the Ignore error handler to the module. The first button connects the Ignore error handler with the module, to ignore all errors the module outputs. The second button inserts the Ignore error handler with a filter. The filter only allows errors that match the current error type to pass through. With the example on the pictures above, Make would ignore only the DataError.
- The purple action button opens the Help Center in a pop-up window.
You have multiple options on how to handle errors in . Make handles some of the most frequent errors by default, and you'll typically need custom error handling only if you need to deal with a specific issue.
The most frequent errors in running scenarios are the RatelimitError and ConnectionError. You can rely on the default error handling for these errors if you enable incomplete executions. The details of the error handling of these errors are in their dedicated articles.
If you need to handle a different error type or if you need to customize the default error handling, you should consider:
- How important is the data the processes? For important , can store partial runs in incomplete executions. You can resolve the incomplete runs manually one by one or retry multiple of them at once.
- What type of error does the module output and how frequently? If the error occurs rarely and it's a temporary error, like the RateLimitError, you can rely on the default error handling. But if the error is critical, like the InvalidAccessTokenError or the InconsistencyError, you should set up error handling.
- What is the impact of the error?If the error has no impact on your data or your processes, you could ignore the error with the Ignore error handler. If the error has a high impact on your processes, you should consider enabling incomplete executions in settings.
For ideas about specific error handling strategies, you can check the list of dedicated articles.
The settings play a key role in error handling. The following list focuses on how some settings influence error handling. For more info about Make settings, check the dedicated article.
Enable this option to store the incomplete run when a module in the outputs an error.
With incomplete executions enabled, stores the state when the error happened as an incomplete execution. You can then check the run, investigate why the error happened, and fix it to finish the run successfully. In addition, all errors turn into warnings.
- doesn't store the incomplete run in these conditions:
- When the error happens on the first module in the scenario. However, you can add the Break error handler to the first module in the . With the Break error handler, stores the incomplete execution even when the first module in the outputs an error.
- When your incomplete executions storage is full. If your incomplete executions storage is full, checks the enable data loss setting:
- If the data loss is disabled, disables the .
- If the data loss is enabled, keeps scheduling runs and discards the incomplete execution if it cannot be stored in your account.
You can read more about incomplete executions in the dedicated article.
Enable this option to postpone running the until the previous run finishes and until all incomplete executions are resolved. Sequential processing makes sure that:
- The runs finish in the same order as they were triggered.
- There is only one execution running at the same time.
Sequential processing has the highest impact on that start with an instant trigger (a webhook) or on that have incomplete executions enabled.
that start with an instant trigger run in parallel by default. For example:
If you have a that starts with a webhook that runs for 5 minutes and you receive a webhook bundle at 12:00 and another one at 12:03, then from 12:03 to 12:05 there will be two instances of the running at the same time in parallel.
In addition, if the instance that started at 12:00 runs longer than usual, for example, until 12:12, the instance that started at 12:03 finishes sooner (at 12:08), even though it started later.
If you want to make sure that the doesn’t start before the previous run finishes, enable the sequential processing.
See webhooks for more information.
The same applies to with the incomplete executions enabled. When there is an error and creates an incomplete execution, postpones the next run until you resolve the incomplete execution or until it’s resolved automatically with the Break error handler.
You can read more in the scenario settings.
The enable data loss setting influences the incomplete executions storage. Enable this option to keep scheduling runs regardless of not having enough space to store incomplete executions.
If you enable data loss, discards the data that doesn't fit into the size limits and continues running the on schedule. Otherwise, disables the scheduling instead.
sets the size limits based on your organization plan. Check the pricing or read more about the scenario settings.
This setting allows you to set how many times in a row the can finish with an error and still keep being scheduled by for subsequent runs. When the finishes with an error the specified number of times in a row, disables the .
To access the setting of the number of consecutive errors, switch the advanced settings toggle in settings. The default number of consecutive errors is 3.
The number of consecutive errors doesn't apply:
- When the is triggered with an instant trigger (webhook). disables instantly triggered immediately if an error happens.
- When an error happens with one of the following types:
- AccountValidationError
- OperationsLimitExceededError
- DataSizeLimitExceededError disables the scheduling immediately after the error happens.
- When you get a warning. If a finishes with a warning, will keep scheduling subsequent runs.
Enable this option to commit changes right after they happen. For example, when a user triggers a that updates their details.
If you disable this option, commits the changes after all modules finish successfully.
The setting affects only modules that support transactions. The modules supporting transactions are labeled with the "ACID" tag. They use a database app most of the time, like the Data Store or MySQL apps.
The modules that don't support transactions make changes immediately and don't provide the rollback functionality.
You can read more about the auto-commit option in the scenario settings article.
Enable this option to commit changes made by the first module in the last. Otherwise, commits the changes in the same order as they happen.
The setting affects only modules that support transactions. The modules supporting transactions are labeled with the "ACID" tag. They use a database app most of the time, like the Data Store or MySQL apps.
The modules that don't support transactions make changes immediately and don't provide the rollback functionality.
You can read more about the commit trigger last option in the scenario settings article.