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 docid\ xzfc2uhei4kmsmhydbnmp docid\ wr8aaeme2ptfar38vxd3p docid 2iifydg6v5dw 94 jkm2i docid 64ex54pn88vgyejrsx10g docid\ hxe6n1fool691glswodgy the error handling route 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 how to identify errors when you are building or checking your in the scenario builder, 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 shows the docid\ n4w0yaeop7a a4vfw ebp and the error message the red fields are quick action buttons you can click the buttons to connect the docid\ xzfc2uhei4kmsmhydbnmp 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 how to approach error handling 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 docid 6zznn7v35herrcjfccp9q the details of the error handling of these errors are in their docid\ oxgtalgvur0yzkn ux9wk 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 docid\ xzfc2uhei4kmsmhydbnmp 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 docid\ xuav7dqhvlanlp6lramgp scenario settings that impact error handling 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 docid\ evar6qlowv4yyuneyv 00 store incomplete executions 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 when you use the docid\ hxe6n1fool691glswodgy in your , you have to enable incomplete executions 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 docid 7 hehdtuu2xyys8 qurub 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 docid 6zznn7v35herrcjfccp9q sequential processing 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 docid 1yhunj8jvzyxip9cf3ps1 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 docid\ evar6qlowv4yyuneyv 00 enable data loss 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 https //www make com/en/pricing or read more about the docid\ evar6qlowv4yyuneyv 00 number of consecutive errors 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 docid\ pdopibceckcbomppkplmy (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 auto commit 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 docid\ evar6qlowv4yyuneyv 00 article commit trigger last 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 docid\ evar6qlowv4yyuneyv 00 article