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.
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.
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.