Overview of error handling

when you are creating {{scenario plural lowercase}} , you might encounter unexpected data or unexpected circumstances {{product name}} notifies you about these events with an error to keep your {{scenario plural lowercase}} reliable and functioning you can use error handlers to deal with errors or unexpected events in your {{scenario singular lowercase}} 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, {{product name}} keeps scheduling your {{scenario singular lowercase}} because {{product name}} can assume that you anticipated the situation and prepared for it there are 5 error handlers in {{product name}} ignore error handler docid\ xzfc2uhei4kmsmhydbnmp resume error handler docid\ wr8aaeme2ptfar38vxd3p commit error handler docid 2iifydg6v5dw 94 jkm2i rollback error handler docid 64ex54pn88vgyejrsx10g break error handler 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 {{product name}} doesn't bill you for handling unexpected events in your {{scenario singular lowercase}} 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, {{product name}} 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 {{scenario singular lowercase}} run ends with an error how to identify errors when you are building or checking your {{scenario singular lowercase}} in the scenario builder, {{product name}} 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 types of errors docid\ n4w0yaeop7a a4vfw ebp and the error message the red fields are quick action buttons you can click the buttons to connect the ignore error handler 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 {{product name}} help center in a pop up window how to approach error handling you have multiple options on how to handle errors in {{product name}} 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 docid 6zznn7v35herrcjfccp9q the details of the error handling of these errors are in their fixing rate limit errors 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 {{scenario singular lowercase}} processes? for important {{scenario plural lowercase}} , {{product name}} can store partial {{scenario singular lowercase}} runs in incomplete executions you can resolve the incomplete {{scenario singular lowercase}} 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 {{scenario singular lowercase}} 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 docid\ xzfc2uhei4kmsmhydbnmp if the error has a high impact on your processes, you should consider enabling incomplete executions in {{scenario singular lowercase}} settings for ideas about specific error handling strategies, you can check the how to handle errors docid\ xuav7dqhvlanlp6lramgp scenario settings that impact error handling the {{scenario singular lowercase}} settings play a key role in error handling the following list focuses on how some {{scenario singular lowercase}} settings influence error handling for more info about make settings, check the scenario settings docid\ evar6qlowv4yyuneyv 00 allow storing of incomplete executions enable this option to store the incomplete {{scenario singular lowercase}} run when a module in the {{scenario singular lowercase}} outputs an error with incomplete executions enabled, {{product name}} stores the {{scenario singular lowercase}} state when the error happened as an incomplete execution you can then check the {{scenario singular lowercase}} run, investigate why the error happened, and fix it to finish the {{scenario singular lowercase}} run successfully in addition, all {{scenario singular lowercase}} errors turn into warnings when you use the error handler docid\ hxe6n1fool691glswodgy in your {{scenario singular lowercase}} , you have to enable incomplete executions {{product name}} doesn't store the incomplete {{scenario singular lowercase}} 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 {{scenario singular lowercase}} with the break error handler, {{product name}} stores the incomplete execution even when the first module in the {{scenario singular lowercase}} outputs an error when your incomplete executions storage is full if your incomplete executions storage is full, {{product name}} checks the overview of error handling /#enable data loss setting if the data loss is disabled, {{product name}} disables the {{scenario singular lowercase}} if the data loss is enabled, {{product name}} keeps scheduling {{scenario singular lowercase}} runs and discards the incomplete execution if it cannot be stored in your account you can read more about incomplete executions in the incomplete executions docid 6zznn7v35herrcjfccp9q sequential processing enable this option to postpone running the {{scenario singular lowercase}} until the previous run finishes and until all {{scenario singular lowercase}} incomplete executions are resolved sequential processing makes sure that the {{scenario singular lowercase}} runs finish in the same order as they were triggered there is only one {{scenario singular lowercase}} execution running at the same time sequential processing has the highest impact on {{scenario plural lowercase}} that start with an instant trigger (a webhook) or on {{scenario plural lowercase}} that have incomplete executions enabled {{scenario plural}} that start with an instant trigger run in parallel by default for example if you have a {{scenario singular lowercase}} 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 {{scenario singular lowercase}} running at the same time in parallel in addition, if the {{scenario singular lowercase}} instance that started at 12 00 runs longer than usual, for example, until 12 12, the {{product name}} instance that started at 12 03 finishes sooner (at 12 08), even though it started later if you want to make sure that the {{scenario singular lowercase}} doesn’t start before the previous run finishes, enable the sequential processing see webhooks docid 1yhunj8jvzyxip9cf3ps1 for more information the same applies to {{scenario plural lowercase}} with the incomplete executions enabled when there is an error and {{product name}} creates an incomplete execution, {{product name}} postpones the next {{scenario singular lowercase}} 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 docid\ evar6qlowv4yyuneyv 00 enable data loss the enable data loss {{scenario singular lowercase}} setting influences the {{scenario singular lowercase}} incomplete executions storage enable this option to keep scheduling {{scenario singular lowercase}} runs regardless of not having enough space to store incomplete executions if you enable data loss, {{product name}} discards the data that doesn't fit into the size limits and continues running the {{scenario singular lowercase}} on schedule otherwise, {{product name}} disables the {{scenario singular lowercase}} scheduling instead {{product name}} sets the size limits based on your organization plan check the {{product name}} pricing or read more about the scenario settings docid\ evar6qlowv4yyuneyv 00 number of consecutive errors this setting allows you to set how many times in a row the {{scenario singular lowercase}} can finish with an error and still keep being scheduled by {{product name}} for subsequent runs when the {{scenario singular lowercase}} finishes with an error the specified number of times in a row, {{product name}} disables the {{scenario singular lowercase}} to access the setting of the number of consecutive errors, switch the advanced settings toggle in {{scenario singular lowercase}} settings the default number of consecutive errors is 3 the number of consecutive errors doesn't apply when the {{scenario singular lowercase}} is triggered with an types of modules docid\ pdopibceckcbomppkplmy (webhook) {{product name}} disables instantly triggered {{scenario singular lowercase}} immediately if an error happens when an error happens with one of the following types accountvalidationerror operationslimitexceedederror datasizelimitexceedederror {{product name}} disables the {{scenario singular lowercase}} scheduling immediately after the error happens when you get a warning if a {{scenario singular lowercase}} finishes with a warning, {{product name}} will keep scheduling subsequent {{scenario singular lowercase}} runs auto commit enable this option to commit changes right after they happen for example, when a user triggers a {{scenario singular lowercase}} that updates their details if you disable this option, {{product name}} 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 docid\ evar6qlowv4yyuneyv 00 article commit trigger last enable this option to commit changes made by the first module in the {{scenario singular lowercase}} last otherwise, {{product name}} 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 docid\ evar6qlowv4yyuneyv 00 article