Committing a Rolled-Back Object by MarkvanMents · Pull Request #10899 · mendix/docs

MarkvanMents · 2026-03-17T15:51:19Z

No description provided.

…d add alt=text to describe microflows.

…ent.

...pplication-logic/microflows-and-nanoflows/activities/object-activities/committing-objects.md

...deling/application-logic/microflows-and-nanoflows/microflows/error-handling-in-microflows.md

MarkvanMents

Thanks for all the comments @basdebakker
I've tried to address them in 89a5f33 - please let me know if it needs more clarification.

...deling/application-logic/microflows-and-nanoflows/microflows/error-handling-in-microflows.md

...pplication-logic/microflows-and-nanoflows/activities/object-activities/committing-objects.md

...deling/application-logic/microflows-and-nanoflows/microflows/error-handling-in-microflows.md

MarkvanMents · 2026-03-23T15:40:44Z

...pplication-logic/microflows-and-nanoflows/activities/object-activities/committing-objects.md

-{{% /alert %}}
+#### What Gets Committed
+
+When you work on an object in memory, Mendix records whether the object has been changed. When you perform a **Commit object(s)** activity, the current value is written to the database and Mendix marks the object as unchanged in memory. This has a couple of consequences that you might not expect:


Updated in ff31fe7

lvanengelen-mx · 2026-03-23T12:32:40Z

...deling/application-logic/microflows-and-nanoflows/microflows/error-handling-in-microflows.md

+
+| Option | Behavior |
+| --- | --- |
+| Rollback (default) |  All changes are reverted to the state before the microflow started, the microflow aborts, and a system error message is shown. |


I think a system error message is only shown if the error is not caught using error handling on a higher level and is allowed to bubble up.

Updated in ff31fe7

Some feedback after our discussion:

All changes are reverted to the state before the microflow started, the microflow aborts,

'the microflow': is it the microflow in which the error handling is defined or the microflow that is called by the Call Microflow action on which error handling is defined.

and a system error message is shown unless custom error handling is added in a microflow which called this one

I would phrase it as cause -> effect, something like: 'if the error is not handled, a system error message is shown'

lvanengelen-mx · 2026-03-23T13:02:44Z

...deling/application-logic/microflows-and-nanoflows/microflows/error-handling-in-microflows.md

+| Option | Behavior |
+| --- | --- |
+| Rollback (default) |  All changes are reverted to the state before the microflow started, the microflow aborts, and a system error message is shown. |
+| Custom with rollback |  All changes are reverted to the state before the microflow started, an error flow is followed, and the microflow's subsequent behavior depends on whether the error handling flow ends with an error or end event. |


'All changes ... state before the microflow started' might be a bit ambiguous here.

In the following setup (client request triggers MF1, MF1 triggers MF2, MF2 triggers MF3, which fails)

request -> MF1 MF1: Start -> ... database stuff ... -> call MF2 Rollback -> End MF2: Start -> ... more database stuff ... -> call MF3 Custom with rollback MF3: FAIL

all database operations in 'database stuff' and 'more database stuff' are reverted. If MF1 did 'call MF2 Custom without rollback' instead, only 'more database stuff' is reverted.

If MF1 did 'call MF2 Custom without rollback' instead, only 'more database stuff' is reverted.

But aren't we talking about Custom with rollback here?

Yes, I just wanted to indicate how the call MF2 error handling configuration influences to which state the database is rolled back. This, to indicate that you do not know to what level the data is rolled back in the case of nested transactions. It could be to the database state at the start of the microflow calling the failing action (i.e. the start of MF2) or a database state at another level entirely.

But doesn't it always end up in the state before this MF is called - the error propagation might then change it again - but for an instant when this particular MF errors the rollback will only go as far as the calling microflow and then work out what to do with the error there?

Not sure if I fully understand, probably because I am not 100% sure about what you mean by state. In the following:

request -> MF1 MF1: S -> A1 -> Call MF2 Rollback -> E MF2: S -> A2 -> Call MF3 Custom with rollback -> E MF3: S -> FAIL

when the Call MF3 fails, execution continues in its error flow (execution state) while the database resets to the last savepoint, which is all the way to the start of MF1.

So we should probably be careful with the word 'state' as well :-)

...pplication-logic/microflows-and-nanoflows/activities/object-activities/committing-objects.md

lvanengelen-mx · 2026-03-23T13:17:24Z

...pplication-logic/microflows-and-nanoflows/activities/object-activities/committing-objects.md

+    1. An error occurs, the microflow ends and data in the database is rolled back to the savepoint.
+    1. You perform a **Commit object(s)** on the object again, but the changes are not written to the database because:
+
+        * The object in memory still has your changes


Unless any other changes were made after the first commit, I do not think this is correct. As the commit succeeded, the changes were applied to the object in memory and the object does not have changes. It's just that the earlier changes are now the current values. I.e. rolling back this object would keep the same values.

Maybe the next bullet point covers it? Or combine with it?

Combined bullets in ff31fe7

To me, 'the object in memory still has changes' here can mean two things:

the attributes have the same value as those that you set, but the original values are still there as well. I.e. rolling back this object will undo your changes

the attributes have the same value as those that you set and the original values are the same. I.e. rolling back this object will keep the same values as the values you set.

lvanengelen-mx · 2026-03-23T13:25:07Z

...pplication-logic/microflows-and-nanoflows/activities/object-activities/committing-objects.md

+
+#### Committing Non-Persistable Entities
+
+Mendix mimics this behavior for non-persistable entities. Committing a non-persistable entity means that you cannot use a rollback object activity to go back to the previous values, although the rollback error handling in a microflow rolls back to the original values.


I do not understand this part. Rollback on NPEs and PEs should work the same. After a commit the original values are replaced with the updated values, so a rollback will revert to the updated values. But that is the same for both NPEs and PEs.

A transaction rollback (which is what "the rollback error handling in a microflow" refers to) will rollback PEs to their original values from before the microflow, regardless of whether they were committed (as in commit object activity, not as in transaction commit).

I am not sure I understand @basdebakker but as far as I know, in general, nothing of the in-memory state of a mendix object is touched on a transaction commit or rollback. The two are independent.

Should we change this - I'm not sure how to make it clearer. I'm trying to say that PEs and NPEs work the same, but obviously I'm not being clear.

What @lvanengelen-mx is saying is just my point (I think). A transaction rollback will rollback any PEs to the state they were in before the transaction started. But it will not affect NPEs. So in that sense they are treated differently.

Bas and I came to the conclusion that we had a misunderstanding on what we meant with PE/NPE: state in memory vs state in the database.

MarkvanMents

Thanks for the comprehensive review.
Resolved some of these (I hope) - there are still two discussions outstanding where I'm not sure what best to say.
Can you have another look and see if there are still changes I need to make.
Thanks for all your work so far.

MarkvanMents · 2026-03-23T15:36:35Z

...deling/application-logic/microflows-and-nanoflows/microflows/error-handling-in-microflows.md

+| Option | Behavior |
+| --- | --- |
+| Rollback (default) |  All changes are reverted to the state before the microflow started, the microflow aborts, and a system error message is shown. |
+| Custom with rollback |  All changes are reverted to the state before the microflow started, an error flow is followed, and the microflow's subsequent behavior depends on whether the error handling flow ends with an error or end event. |


But doesn't it always end up in the state before this MF is called - the error propagation might then change it again - but for an instant when this particular MF errors the rollback will only go as far as the calling microflow and then work out what to do with the error there?

...pplication-logic/microflows-and-nanoflows/activities/object-activities/committing-objects.md

MarkvanMents · 2026-03-23T15:40:44Z

...pplication-logic/microflows-and-nanoflows/activities/object-activities/committing-objects.md

-{{% /alert %}}
+#### What Gets Committed
+
+When you work on an object in memory, Mendix records whether the object has been changed. When you perform a **Commit object(s)** activity, the current value is written to the database and Mendix marks the object as unchanged in memory. This has a couple of consequences that you might not expect:


Updated in ff31fe7

MarkvanMents · 2026-03-23T15:41:13Z

...pplication-logic/microflows-and-nanoflows/activities/object-activities/committing-objects.md

+    1. An error occurs, the microflow ends and data in the database is rolled back to the savepoint.
+    1. You perform a **Commit object(s)** on the object again, but the changes are not written to the database because:
+
+        * The object in memory still has your changes


Combined bullets in ff31fe7

MarkvanMents · 2026-03-23T15:42:30Z

...pplication-logic/microflows-and-nanoflows/activities/object-activities/committing-objects.md

+
+#### Committing Non-Persistable Entities
+
+Mendix mimics this behavior for non-persistable entities. Committing a non-persistable entity means that you cannot use a rollback object activity to go back to the previous values, although the rollback error handling in a microflow rolls back to the original values.


Should we change this - I'm not sure how to make it clearer. I'm trying to say that PEs and NPEs work the same, but obviously I'm not being clear.

MarkvanMents · 2026-03-23T15:42:50Z

...deling/application-logic/microflows-and-nanoflows/microflows/error-handling-in-microflows.md

+
+| Option | Behavior |
+| --- | --- |
+| Rollback (default) |  All changes are reverted to the state before the microflow started, the microflow aborts, and a system error message is shown. |


Updated in ff31fe7

Committing a Rolled-Back Object

aebf432

MarkvanMents added Needs R&D technical verification Internal WIP Needs Support verification labels Mar 17, 2026

MarkvanMents self-assigned this Mar 17, 2026

MarkvanMents added 3 commits March 17, 2026 16:57

Add that changes from Commit object(s) are not visible to other users.

d412964

Update Error handling to reference clarified rollback information, an…

cf40ca5

…d add alt=text to describe microflows.

Add and rewrite information which was in the Mx8 version of the docum…

1193b71

…ent.

basdebakker reviewed Mar 20, 2026

View reviewed changes

...pplication-logic/microflows-and-nanoflows/activities/object-activities/committing-objects.md Outdated Show resolved Hide resolved

basdebakker reviewed Mar 20, 2026

View reviewed changes

...pplication-logic/microflows-and-nanoflows/activities/object-activities/committing-objects.md Outdated Show resolved Hide resolved

basdebakker reviewed Mar 20, 2026

View reviewed changes

...deling/application-logic/microflows-and-nanoflows/microflows/error-handling-in-microflows.md Outdated Show resolved Hide resolved

basdebakker reviewed Mar 20, 2026

View reviewed changes

...deling/application-logic/microflows-and-nanoflows/microflows/error-handling-in-microflows.md Outdated Show resolved Hide resolved

basdebakker reviewed Mar 20, 2026

View reviewed changes

...deling/application-logic/microflows-and-nanoflows/microflows/error-handling-in-microflows.md Outdated Show resolved Hide resolved

basdebakker reviewed Mar 20, 2026

View reviewed changes

...deling/application-logic/microflows-and-nanoflows/microflows/error-handling-in-microflows.md Outdated Show resolved Hide resolved

Respond to review by @basdebakker

89a5f33

MarkvanMents commented Mar 23, 2026

View reviewed changes

lvanengelen-mx reviewed Mar 23, 2026

View reviewed changes

...pplication-logic/microflows-and-nanoflows/activities/object-activities/committing-objects.md Outdated Show resolved Hide resolved

lvanengelen-mx reviewed Mar 23, 2026

View reviewed changes

Updated from second review

ff31fe7

MarkvanMents commented Mar 23, 2026

View reviewed changes


		#### Committing Non-Persistable Entities

		Mendix mimics this behavior for non-persistable entities. Committing a non-persistable entity means that you cannot use a rollback object activity to go back to the previous values, although the rollback error handling in a microflow rolls back to the original values.

Conversation

MarkvanMents commented Mar 17, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

MarkvanMents left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment was marked as resolved.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lvanengelen-mx Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lvanengelen-mx Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

lvanengelen-mx Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MarkvanMents left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

lvanengelen-mx Mar 23, 2026 •

edited

Loading

lvanengelen-mx Mar 25, 2026 •

edited

Loading

lvanengelen-mx Mar 23, 2026 •

edited

Loading