Auto commit entries are stored in the following table: system$autocommitentry
You’ll find there the ids of autocommitted objects and eventually the type of objects that are not properly committed.
Then you just need to search where those objects are created in the model and ensure they are explicitly committed.
In my case, they were caused by the ExcelImporter when I generate templates directly from the model instead of using the UI.
The issue isn't the autocommit feature, but the lack of correct committing in your own model.
โAutocommit does only exists to ensure that when you commit an object (owner of the association) with a reference to a not (yet) committed object to ensure that the association is correctly stored in the database.
BUT you still need to commit the autocommitted object. Never ever trust the autocommit as a full commit.
So when dealing with referenced data in a microflow, commit everything in a commit activity explicitly.
I guess that the lognodes connectionbus_Update and/or DataStorage_QueryHandling will provide info about autocommits
Trace back to the microflow where the data got changed and commit the data right then and there.
Autocommit is a (too) complex feature that often leads to unexpected results. Therefor it is a good thing that autocommit is about to get replaced by something better (hopefully), see https://forum.mendix.com/link/ideas/650
You might want to upvote that idea.