--- title: Commit error handler slug: commit-error-handler description: Add Commit error handler to stop scenario execution when an error occurs and save the processed changes image: https://archbee-image-uploads.s3.amazonaws.com/oAyFj2GHlBeBVWF5OAir2/wBtMo3upNcqLJ7ttcAnF7_11.png docTags: createdAt: 2025-02-03T13:29:13.656Z --- The **Commit** error handler stops the scenario run and commits changes in your database apps. It tells the database - Everything you did right before this error was intentional, and instructs Make so keep those changes. If your scenario is not using apps that support transactions, like **MySQL** or **Data store**, the **Commit** error handler just stops the scenario. :::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. ::: The bundle that caused the error doesn't go through the rest of the scenario flow. Make 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 scenario 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 scenario . When an error occurs, the Commit handler stops the scenario 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 scenario 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 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** looks**: ![](https://api.archbee.com/api/optimize/oAyFj2GHlBeBVWF5OAir2/hAt8L-RCHcqlRX1Zv9ITu_uuid-a20c3804-3600-efbd-3e63-6ee8604bee5a.png) When we would run the example scenario, we would get the `BundleValidationError`: ![](https://api.archbee.com/api/optimize/oAyFj2GHlBeBVWF5OAir2/eV9s60is4o30uYvPGyHHU_uuid-d0cd6900-234c-21a1-c35c-e5ee696e538c.png) ::::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 what how to handle this error using a Commit error handler.** ::::WorkflowBlock :::WorkflowBlockItem Right-click the data store module that failed and click **Add error handler.** ::: :::WorkflowBlockItem From the list of error handlers, click** Commit**. ::: :::WorkflowBlockItem 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. ::: :::WorkflowBlockItem In the bottom panel, click the** Scenario settings**. ::: :::WorkflowBlockItem In **Store incomplete executions**, select** Yes.** ::: :::WorkflowBlockItem 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**. The Commit error handler would stop processing the bundle in the scenario and save changes to your data in database apps. Make wouldn't process the remaining bundles. ![](https://api.archbee.com/api/optimize/oAyFj2GHlBeBVWF5OAir2/mNQWejvkDQgp6I0tGStjl_uuid-c5f5a530-6064-5b5f-6173-43065e78feff.png) **Let's check the data in the data store as well.** {we need a better example} Before running the scenario, the data store contained the following data: ![](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`. After running the scenario, Make would update the data in the data store: ![](https://api.archbee.com/api/optimize/oAyFj2GHlBeBVWF5OAir2/wZicTI1EIcTtXTIDeHgq3_uuid-0f0aedfd-c5cc-0a42-48e8-e78595379bf3.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. 3. The **Commit** error handler saves the update in the first module, but 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`. 4. Make doesn't update the third row because the **Commit** error handler stopped the scenario run already. The data in the third row remain the same: `ID = 3, Name = Test 3`.