Created object persists in memory after custom error handling with rollback

Microflow demonstrating the issue When using the “custom with rollback” error handler, the created object is not committed to the database but is still retained in memory and returned by the microflow. It does not matter whether the changed object is committed or not. The non-custom rollback error handler does not show this behaviour. Is this an intended effect? I can not find it in the documentation.
3 answers


While I have never tested this out, I have a few thoughts:

  • if you allow the microflow to complete and then try to retrieve the created object separately (in a datagrid maybe, or another microflow), is the object still there?
  • This post:  touches on this.  Seems to say that using custom error handling enables you to complete a bunch of actions before the rollback happens.  So custom error handling could give you as the developer a second chance to commit the object after correcting the error encountered.

I am curious what you find.



I was curious about this, so I did some further testing.  I created a microflow similar to the one you shared and tried to commit the newly created object in the error handling flow.  The commit didn’t throw an error, but the object was not saved to the database.  Next I created a new object and copied attributes from the first (rolled back) object.  I successfully copied and committed the new object.  The original object, while it can be accessed in the microflow, is gone after that.  

So it seems to me that this behavior is so that, as a developer, I can recover gracefully from an error, without losing data if I choose not to.


Good question and maybe somebody from Mendix can chime in here. From the documentation

The Rollback object action can be used to undo changes (that have not been committed) made to the object in the part of the flow preceding the activity. Furthermore, it deletes objects that have been created but never committed.

So from the documentation it seems that retaining the newly created object is indeed wrong. I would create a test project and create a support ticket.





There are a couple of different things that I see mentioned here in this thread. I’ll try to explain them all.

Error handling type: custom with rollback

This rolls back the database transaction and allows the microflow to continue on the error handling path. It will not change nor roll-back the state of the objects that are still in memory because they are persisted in earlier microflow activities (either by a Commit-Action or a Create/Change action that has commit set to yes). As a result of that, recommitting the same objects will not cause a change as the runtime no longer knows which members are changed or whether the object was created or not. If you want to change the data in the database again you should indeed copy the changes to another/new version of the same object.

Error handling type: custom without rollback

This will not rollback the transaction in the database, meaning that all successful committed changes in objects within activities of the microflow preceding the current failing activity will stay in the database. The microflow continues on the error handling path allowing you to do different things to circumvent the error.

Rollback activity

This is a whole different thing as it will not influence the database transaction. It will remove all changes of the specified object or remove the object from the state when it still was created-but-not-committed. It has no interaction with the database at all.


The observed behavior is indeed the intended effect. If this explanation is helpful I will make sure that this is updated in the documentation.