Overview of error handling

what are error handlers error handlers are tools in that allow you to deal with errors or unexpected events in your an error handler is connected to a module and is the last module of the error handling route when the module outputs an error, the error handler prevents the scenario from stopping instead, it intercepts the error and executes the scenario based on the error handler’s configuration when to use error handlers when your scenarios encounter errors, they hit a roadblock if you have incomplete executions https //help make com/incomplete executions on, your scenario stops and the execution is moved to the incomplete executions tab this is your manual queue you must then manually intervene, identify the cause, fix the issue, and resume your scenario from where you left off if you find yourself manually fixing the same recurring errors, you can introduce error handlers to automate the recovery process instead of letting the scenario stop and wait for you, an error handler allows the scenario to follow a predefined logic, such as retrying the task automatically or skipping the error, keeping your workflows moving without your intervention for example you built a scenario that syncs contacts from a web from to your crm a user fills out a form on your website your scenario takes that data and sends it to your crm your crm configuration requires a phone number, but some users leave that field blank on your form when you run your scenario, it fails without an error handler the scenario stops the contact isn't created in your crm, and the execution moves to the incomplete executions tab (if enabled) you have to manually intervene, type in a dummy number such as "000 000 0000" in the phone number field, and continue with an error handler to handle this issue, you add a resume error handler you instruct your resume error handler to use a substitute value for missing phone numbers and continue the scenario the scenario finishes successfully the contact is created in hubspot with the substitute date in the phone field, and you don't have to intervene further since the error isn't a glitch that will fix itself (like a server being down), an incomplete execution would just sit there forever until you manually typed in a value the resume handler automates that for you by providing a substitute to maintain system reliability and operational integrity, automatically captures errors without stopping your or losing your data this is done using error handlers or error handling directives adheres to industry standard error codes and definitions however, it may be possible that the third party may not fully comply with these standards different types of error handlers the following topic provides a quick reference to working with error handlers in if you want to learn more about individual error handlers, check the dedicated articles in this section of the help center there are five error handlers in retry the retry error handler removes the failing bundle from the scenario flow it stores the error details and remaining steps as an incomplete execution, and allows the rest of the scenario to continue running retries the incomplete runs according to your configuration or stores them until you resolve them yourself make processes the rest of the bundles in the scenario flow normally the scenario ends with a warning status scenario stopped no scenario status warning to learn more, see the retry error handler docid\ cptwi8yi45zl3m5slzjnv page skip the skip error handler skips the error and removes the affected bundle from the flow, allowing the to continue with the next bundle it’s useful when occasional invalid data is expected and doesn’t impact your process it prevents the from stopping and marks the run as successful , even if an error occurs scenario stopped no scenario status success to learn more, see the skip error handler docid\ j9xcttcbfdwq3q3u144fn page resume the resume error handler replaces the failed module’s output with a predefined substitute output when an error occurs if the module fails, the scenario continues to run using the substitute value in the subsequent steps this allows the scenario to continue running smoothly using that data instead of stopping scenario stopped no scenario status success to learn more, see the resume error handler docid\ wr8aaeme2ptfar38vxd3p page commit the commit error handler stops the scenario run and commits all changes made up to that point in the database apps if the scenario doesn’t use transactional apps (such as mysql or data store), the handler simply stops the scenario make doesn't process the rest of the modules in the scenario flow the scenario ends with a warning status scenario stopped yes scenario status w arning to learn more, see the commit error handler error handler docid\ vx 5byw32d43uwvobwe7t page rollback make stops the scenario run and reverts any changes in modules that support transactions the remaining modules are not processed, the scenario is deactivated after repeated runs with errors, and the run ends with an error status rollback is the default error handling if you don't set any error handling and when you keep incomplete executions docid 6zznn7v35herrcjfccp9q disabled scenario stopped yes scenario status error to learn more, see the rollback error handler docid 64ex54pn88vgyejrsx10g page the error handling route in , an error handling route is visually identified by a transparent, dotted connection these routes define the logic path the scenario follows when a module encounters an exception 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 occurs if no module outputs an error in the error handling route, skips 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 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 when dealing 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 dedicated articles 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 skip the error with the skip error handler docid\ j9xcttcbfdwq3q3u144fn 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 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 dedicated article 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 retry error handler docid\ cptwi8yi45zl3m5slzjnv 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 retry error handler to the first module in the with the retry 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 docid\ sn7mce4qml q6wdtoocsy 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 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 webhooks 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 retry error handler you can read more in the scenario settings 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 pricing https //www make com/en/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 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 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 execute 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 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 docid\ evar6qlowv4yyuneyv 00 article