strange debugging behaviour. Looks like one breakpoint is skipped over

1
I have the following issue with the microflow below. As you can see, there are 3 active breakpoints. The debugger hits the 1st and and the 3rd, but never the 2nd. The retrieve seems to work as designed, so I assume there is no error – I would see that anyway, wouldn’t I? When I start the application, I get a matching error: “Error applying breakpoint: Microflow object with object id '69d3b14a-e239-45e6-92e7-f0e30996fbf5' not found in microflow 'Inventory.DS_Orders_CountPending_Admin'” Is there anything I can do here or are there activities, that don’t allow breakpoints?  
asked
3 answers
7

Certain activities in a microflow are optimized for performance.  One of those is a database retrieve followed by an aggregate function (count, sum, etc.)  This combination of activities is handled by the database server and not the Mendix app server.  All of the work for this is performed by the database server and the only thing that is returned to the microflow is $Count.  This is why you can’t break on the retrieve.

Note that if the retrieved list is used later in the microflow for a different purpose, to iterate over in a loop for example, the list will be returned to the microflow and you would be able to break on the retrieve action.

answered
1

A database retrieval in combination with the count will be treated as a combined activity to form an optimized DB retrieval. So, you will never be able to stop the debugger at DB retrieval that is accompanied by count.

answered
1

damn, that was exactly the reason why I tried to trace it. Wanted to see the resulting query but got stuck on the disappearing breakpoint…

Maybe the error message could be improved to give this as a possible reason for not finding the breakpoint. I guess a static analyzer would also tell us what we need to know.

answered