--- title: Rollback error handler slug: rollback-error-handler description: Apply Rollback error handler to stop scenario execution when an error occurs and revert changes image: https://archbee-image-uploads.s3.amazonaws.com/oAyFj2GHlBeBVWF5OAir2/NP6nug-mmwKjroUITMbsg_11.png docTags: createdAt: 2025-02-03T13:29:13.656Z --- The **Rollback** error handler stops the scenario and reverts any changes made by modules that support transactions, such as MySQL or Data Store. Make 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 Make 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. :::hint{type="success"} 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 scenario contains five modules. 1. **JSON** - **Parse JSON** provides test data in the form of an array of three record IDs. 2. **Iterator** splits the array into individual bundles. 3. **Data store** - **Update a record**: Updates the data in the data store. 4. **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: ::Image[]{src="https://api.archbee.com/api/optimize/oAyFj2GHlBeBVWF5OAir2/IGuzVI2USP_2J2uaI6DiO_uuid-38a27efa-f066-3ba0-d77f-c1fac59dbb6a.png" size="100" width="882" height="254" position="center" darkWidth="882" darkHeight="254" showCaption="false" indent="2"} 5. The mapping inserts a `null` value into the required **Key** field, which always creates the `BundleValidationError`. 6. 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. 7. **Slack** - **Send a message**: Sends a message to a private testing channel. **This is how the example **scenario** look**s: ![](https://api.archbee.com/api/optimize/oAyFj2GHlBeBVWF5OAir2/hAt8L-RCHcqlRX1Zv9ITu_uuid-a20c3804-3600-efbd-3e63-6ee8604bee5a.png) When we run the example scenario, we would get the `BundleValidationError`: ::::VerticalSplit{layout="middle"} :::VerticalSplitItem ![](https://api.archbee.com/api/optimize/oAyFj2GHlBeBVWF5OAir2/eV9s60is4o30uYvPGyHHU_uuid-d0cd6900-234c-21a1-c35c-e5ee696e538c.png) ::: :::VerticalSplitItem ![](https://api.archbee.com/api/optimize/oAyFj2GHlBeBVWF5OAir2/CNPg8JnCTdNcxaACINlIU_uuid-5e505ecc-ffa2-af6c-9a23-e625392bf169.png) ::: :::: **Let's see how to handle this error using a Rollback error handler**. ::::WorkflowBlock :::WorkflowBlockItem Right-click the module that is causing the error. In the menu, select **Add error handler**. ::: :::WorkflowBlockItem Select the **Rollback** error handler. ::: :::WorkflowBlockItem Optional: Go to scenario settings and disable the **Auto-commit** option. ::: :::WorkflowBlockItem 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 that support transactions undo changes. ::: :::WorkflowBlockItem Save your scenario. ::: :::: You've successfully added the **Rollback** error handler to your scenario. **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 scenario. When an error occurs in the **Data store** module, the scenario stops and Make reverts changes made by the erroring bundle in modules that support transactions. Make wouldn't process the remaining bundles. ![](https://api.archbee.com/api/optimize/oAyFj2GHlBeBVWF5OAir2/hFW_Qzof1gOSgooi8bFke_uuid-1efea139-a1c9-35b8-bc89-f89428a18bd5.png) **Let's check the data in the data store as well.** In this example, before running the scenario, the data store contained the following data: {we need a better example} ![](https://api.archbee.com/api/optimize/oAyFj2GHlBeBVWF5OAir2/oRZrCTIj9zuzZsnPsPb73_uuid-5d1bac2c-e430-eeb5-bc8b-220215ade799.png) ::::VerticalSplit{layout="middle"} :::VerticalSplitItem ![](https://api.archbee.com/api/optimize/oAyFj2GHlBeBVWF5OAir2/hfIMYjRdotNKBy-0o3Ev8_uuid-41ecf051-2dae-90c9-bfdd-288c3f64d0c0.png) ::: :::VerticalSplitItem ![](https://api.archbee.com/api/optimize/oAyFj2GHlBeBVWF5OAir2/nwkQQ7SQTHK8_9R5xT9D-_uuid-c10413d2-2a9d-4d96-fe28-e86daff85b73.png) ::: :::: 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 settings, Make reverts the changes that happened when Make was processing the bundle in modules that support transactions. ![](https://api.archbee.com/api/optimize/oAyFj2GHlBeBVWF5OAir2/m_T7FG48xXzUiNpMD615w_uuid-9e689f33-25d5-47ac-7f0d-a0e7ff42cf8b.png) 1. The first bundle of data gets through the scenario 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`. 2. 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. 3. Make doesn't update the third row because the **Rollback** error handler stopped the scenario run already. The data in the third row remain the same: `ID = 3, Name = Test 3`. If you keep the **Auto-commit** option enabled, Make reverts the changes made by the module that output the error if the module supports transactions. ![](https://api.archbee.com/api/optimize/oAyFj2GHlBeBVWF5OAir2/VnE9UupIhuh__HkPObLdL_uuid-3ce21539-b9cc-0fbf-da10-2459ce8e2bf2.png) 1. The first bundle of data gets through the scenario flow successfully and updates the first row of data in the data store both times. Make commits all changes and they cannot be rolled back later. 2. The first row contains the update from the second **Update a record** module: `ID = 5, Name = Test 5`. 3. The second bundle gets to the first **Update a record** module successfully. Make commits all changes and they cannot be rolled back later. The second bundle causes an error in the second module. 4. The **Rollback** error handler prevents the update in the second module and stops the scenario. The second row contains the update from the first module only: `ID = 4, Name = Test 4`. 5. Make doesn't update the third row because the **Rollback** error handler stopped the scenario 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 run and undo changes when the module outputs an error.