Commit error handler

the commit error handler stops the run and commits changes in your database apps i t tells the database everything you did right before this error was intentional, and instructs so keep those changes if your is not using apps that support transactions, like mysql or data store , the commit error handler just stops the modules that support transactions are labeled with the "acid" label before you use the rollback or commit error handlers, take a look at the auto commit scenario setting docid\ evar6qlowv4yyuneyv 00 first the bundle that caused the error doesn't go through the rest of the flow doesn't process the rest of the bundles when to use it use commit error handler when you want to confirm all the changes that were made before the error occurred you want the entire to stop immediately after an error so you can investigate, rather than letting subsequent modules continue to run for more information about error handling strategies check the overview of error handling docid\ sn7mce4qml q6wdtoocsy how the commit error handler works the commit error handler acts as a save and exit function for your when an error occurs, the commit handler stops the run immediately and ensures that any changes made to your database apps (like data store or mysql) up to that point are permanently saved use a commit error handler in this example, we have a that updates a data store twice if the second update fails, the commit handler ensures the first update is permanently saved before stopping the scenario this demo contains five modules json parse json provides test data in the form of an array of three record ids iterator splits the array into individual bundles data store update a record updates the data in the data store data store update a record this module updates the data again this time the module works differently in the module mapping, there is a mapping that intentionally creates an error the mapping inserts a null value into the required key field, which always creates the bundlevalidationerror having two data store modules doing the same thing, but one of them failing, will make a good example for the commit and rollback error handlers slack send a message sends a message to a private testing channel this is how the example looks when we would run the example , we would get the bundlevalidationerror let's see what how to handle this error using a commit error handler right click the data store module that failed and click add error handler from the list of error handlers, click commit configure the automatically complete execution by toggling between yes or no if you set it as yes , the system automatically retries depending upon the the number of attempts and the interval (e g , try 3 more times, every 15 minutes) if you leave this as no , the error will stay in your incomplete executions tab until you resolve it in the bottom panel, click the scenario settings in store incomplete executions , select yes click save you've successfully added the commit error handler to the update a record module what happens when you run the scenario after you add a commit error handler t he commit error handler would stop processing the bundle in the and save changes to your data in database apps wouldn't process the remaining bundles let's check the data in the data store as well \<font color="#be185d">{we need a better example}\</font> before running the , the data store contained the following data the mappings for the update a record modules the first module updates the id column to the number 4 and the name column to the text test 4 the second module updates the id column to the number 5 and the name column to the text test 5 after running the , would update the data in the data store the first bundle of data gets through the flow successfully and updates the first row of data in the data store both times the first row contains the update from the second update a record module id = 5, name = test 5 the second bundle gets to the first update a record module successfully, but causes an error in the second module the commit error handler saves the update in the first module, but prevents the update in the second module and stops the the second row contains the update from the first module only id = 4, name = test 4 doesn't update the third row because the commit error handler stopped the run already the data in the third row remain the same id = 3, name = test 3