Rollback error handler

the rollback error handler stops the scenario and reverts any changes made by modules that support transactions, such as mysql or data store cannot undo actions made by modules that don't support transactions, like gmail > send an email or dropbox > delete a file when an error occurs, the failed bundle does not continue through the scenario flow and doesn't process any remaining bundles the scenario run is marked as an error in the scenario history, but the scenario itself will not be disabled 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 when to use it use the rollback error handler when data integrity is critical and any changes made during a failed run must be undone for example tom tries to book a hotel room online which requires a deposit the hotel attempts to charge the tom's payment card, but the card is declined the rollback error handler reverts the hotel reservation everything is undone, no hotel is reserved and the hotel reverts to it original room availability for more information about error handling strategies check the overview of error handling docid\ sn7mce4qml q6wdtoocsy how the rollback error handler works when a module encounters an error, the rollback error handler stops the scenario and reverts changes made by the erroring bundle in modules that support transactions the behaviour depends on whether the auto commit option is enabled in your scenario settings auto commit enabled — only the module that produced the error can revert its changes changes made by previous modules in the scenario are committed and cannot be rolled back auto commit disabled — all changes made during the bundle's execution across every transaction supported module can be reverted use the rollback error handler in this example, we have a scenario that updates a data store and then sends a slack message if the data store update fails because of a missing value (a bundlevalidationerror), make must stop the scenario and revert any changes made 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 look s when we run the example , we would get the bundlevalidationerror let's see how to handle this error using a rollback error handler right click the module that is causing the error in the menu, select add error handler select the rollback error handler optional go to settings and disable the auto commit option when an error happens, the module that outputs the error reverts changes if the module supports transactions if you disable the auto commit option, all modules in the that support transactions undo changes save your you've successfully added the rollback error handler to your what happens when you run the scenario after adding the rollback error handler when the rollback error handler is added to the update a record module, the rollback error handler would stop processing the bundle in the when an error occurs in the data store module, the stops and reverts changes made by the erroring bundle in modules that support transactions wouldn't process the remaining bundles let's check the data in the data store as well in this example, before running the , the data store contained the following data \<font color="#be185d">{we need a better example}\</font> 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 if you disable the auto commit option in the settings, reverts the changes that happened when was processing the bundle in modules that support transactions 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 rollback error handler reverts the update from the second bundle and stops the doesn't update the third row because the rollback error handler stopped the run already the data in the third row remain the same id = 3, name = test 3 if you keep the auto commit option enabled, reverts the changes made by the module that output the error if the module supports transactions the first bundle of data gets through the flow successfully and updates the first row of data in the data store both times commits all changes and they cannot be rolled back later 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 commits all changes and they cannot be rolled back later the second bundle causes an error in the second module the rollback error handler 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 make doesn't update the third row because the rollback error handler stopped the run already the data in the third row remain the same id = 3, name = test 3 you can use the rollback error handler to stop the run and undo changes when the module outputs an error