Lately more and more I am noticing that retrieves over associations are returning empty for objects that do exist. This is so far only happening in our production environment, where our memory heap is often near its limit, and I have yet to be able to reproduce it locally. This is happening seemingly arbitrarily, pressing the same button again at a later time with no changes to the input does often work. My presumption is that the garbage collector is removing these objects. I have been having these issues ever since we moved to higher versions over Mendix 5 and I know that around this time some major changes to the garbage collector have been made. I notice this mostly happening in microflows that are ran in the background, so for now my solution is to move more actions to the foreground and to build in a retrieve over database whenever the retrieve over association returns empty. Does anyone else share these experiences?
I've noticed similar behavior in recent Mendix versions (6.3.1. at the moment).
In the most clear-cut example, I have a subflow that only does two things:
Set a log message to confirm that the single input parameter is not empty (for testing)
Retrieve over association a list of items for the input parameter and return the list as output of the flow.
Most of the time, this works as it should, but with some frequency the 'retrieve over association' action will give a nullpointer exception, despite the fact that the log confirms the input parameter is present.
It appears as if the memory references for the associated objects exist, but that the actual objects have been GCed.
Yes, I have seen this happening also. And indeed the problem is that you never can reproduce the error. Trying to do a same setup in a new project always works as expected. But the last couple of months I had to change over reference to database in four or five places in our model.
I remember a specific case on Mendix 5.15 where I built a microflow specifically to retrieve an object over association. If this returned empty it would try again from database and then return the result.
Like in your case we were not able to consistently reproduce the problem, but after my fix it consistently worked.
So yes, I think I recognize your issue, but I was also able to reproduce it locally, although not consistently.