Hi all, I’ve got the autocommit error, but I am unsure how it happened. 2022-08-30T16:57:17.168106 [APP/PROC/WEB/0] WARNING - Core: Some autocommitted objects still existed on logout for session 'firstname.lastname@example.org'. 2022-08-30T16:57:17.168129 [APP/PROC/WEB/0] Autocommitted objects are newly created objects which were not yet committed, but are inserted into the database because an associated object was committed. 2022-08-30T16:57:17.168145 [APP/PROC/WEB/0] Autocommitted objects should explicitly have been committed, please check your model and apply the necessary changes. The autocommitted objects have been deleted from the database to prevent database corruption.Number of autocommitted objects per type which still existed for this session: 2022-08-30T16:57:17.168182 [APP/PROC/WEB/0] - System.AutoCommitEntry: 2 object(s). 2022-08-30T16:57:17.168275 [APP/PROC/WEB/0] - DailySupportRecord.PlannedActivity: 1 object(s). 2022-08-30T16:57:17.168332 [APP/PROC/WEB/0] - DailySupportRecord.Activity: 1 object(s). As you can see I have added error handling to each commit, so in theory (if I understand correctly) an auto-commit issue on PlannedActivity cannot happen here. The ‘NewCoreNotication’ was committed and is present in the database, however, the PlannedActivity and Acvtiviy were removed by the auto-commit feature. My question is how did this happen? If there was an issue saving the PlannedActivity or Activity object it would error and stop the flow. Thus, the autocommit error should not happen, by the time the microflow gets to the commit ‘NewCoreNotification’ it the other objects should either be committed or the microflow errored out. Secondary question: should I be adding rollback onto the error flows? The error handling is set to custom with rollback, does this rollback just the one object or everything handled in the microflow?
The second question I can answer for you. The rollback rolls the whole microflow back. Not just the singe object.
And may be that solves your first question also, because may be that rollback could set those other objects back into the autocommit state due to the rollback. In cases like these I would always go for the custom without rollback because you can then model out what should be committed and what should get deleted.