Rollback error handler

the rollback error handler stops the {{scenario singular lowercase}} run and reverts changes made by modules that support transactions they always use a database app, like mysql or data store {{product name}} cannot undo actions made by modules that don't support transactions, like gmail > send an email or dropbox > delete a file the bundle that caused the error doesn't continue in the {{scenario singular lowercase}} flow in addition, {{product name}} doesn't process any remaining bundles {{product name}} marks the {{scenario singular lowercase}} run as an error in the {{scenario singular lowercase}} history {{product name}} won't disable the {{scenario singular lowercase}} because of consecutive errors modules that support transactions are labeled with the "acid" label before you use the rollback or commit error handlers, take a look at the scenario settings docid\ evar6qlowv4yyuneyv 00 first for example this demo {{scenario singular lowercase}} contains five modules the {{scenario singular lowercase}} is useful for tests and showing the effect of an error handler 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 {{scenario singular lowercase}} looks when we would run the example {{scenario singular lowercase}} , we would get the bundlevalidationerror if we added the rollback error handler to the update a record module, the rollback error handler would stop processing the bundle in the {{scenario singular lowercase}} {{product name}} wouldn't process the remaining bundles let's check the data in the data store as well before running the {{scenario singular lowercase}} , 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 if you disable the auto commit option in the {{scenario singular lowercase}} settings, {{product name}} reverts the changes that happened when {{product name}} was processing the bundle in modules that support transactions the first bundle of data gets through the {{scenario singular lowercase}} 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 {{scenario singular lowercase}} {{product name}} doesn't update the third row because the rollback error handler stopped the {{scenario singular lowercase}} run already the data in the third row remain the same id = 3, name = test 3 if you keep the auto commit option enabled, {{product name}} reverts the changes made by the module that output the error if the module supports transactions the first bundle of data gets through the {{scenario singular lowercase}} flow successfully and updates the first row of data in the data store both times {{product name}} 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 {{product name}} 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 {{scenario singular lowercase}} 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 {{scenario singular lowercase}} 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 {{scenario singular lowercase}} run and undo changes when the module outputs an error for more information about error handling strategies check the overview of error handling docid 7 hehdtuu2xyys8 qurub undo changes to your data when an error happens with the rollback error handler, you can stop the {{scenario singular lowercase}} and undo changes when the module outputs an error you can only undo changes in modules that support transactions modules that support transactions are labeled with the "acid" label before you use the rollback or commit error handlers, take a look at the scenario settings docid\ evar6qlowv4yyuneyv 00 first for example, the following {{scenario singular lowercase}} outputs an error in the data store app module to stop the {{scenario singular lowercase}} and undo changes where possible when an error happens, follow the steps right click the module that is causing the error in the menu, select add error handler select the rollback error handler optional go to {{scenario singular lowercase}} 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 {{scenario singular lowercase}} that support transactions undo changes save your {{scenario singular lowercase}} you added the rollback error handler to your {{scenario singular lowercase}} when an error occurs in the data store module, the {{scenario singular lowercase}} stops and {{product name}} reverts changes made by the erroring bundle in modules that support transactions