Object with id [MendixIdentifier:: id=43347111414534361 objectType=XXXX.XX entityID=123] could not be retrieved after upgrade to 484
We are testing an upgrade to the 484 release (from 472) and encounter the following Warning: Object with id '[MendixIdentifier:: id=43347111414534361 objectType=XXXX.XX entityID=123]' could not be retrieved. The Warning is displayed several times in the console and seems to result in popup forms (new record) being greyed out (seems like View only forms). The warning is displayed when I press a microflow button to create a new record and open a form. The microflow contains 3 steps, Create Action (no commit), Change Action (no commit), Show form of object created in step 1. When debugging I see that the ID mentioned in the Warning is in fact the ID of the object created in step 1. As such the issue seems to be related to the object which has not been committed to the database yet. The issue is not restricted to this 1 flow and occurs in several (comparable) flows using different objects. EDIT: More information: Issues are encountered when doing a local deployment on a DEV PC. We use a SQL server 2008 database. We do not have any specific settings for Persistent sessions in this environment. The object X involved does have a generalisation Y. I switched on Core logging, below the part right before and after the warning: 2014-07-18 11:20:04.259 Core Garbage collected 0 objects for session 72d06b66-008f-4e15-93eb-e1e7a9583ba9 2014-07-18 11:20:04.596 Core Creating system session 'b6990a8a-286c-4dc1-82aa-a269bcecfe1e' 2014-07-18 11:20:20.201 Core Succesfully added id [MendixIdentifier:: id=43347146414534661 objectType=XXXXX.XX entityID=154] to client rootset. 2014-07-18 11:20:20.202 Core Creating system session '937c4de2-b046-4cbc-a6ab-cdc96d41c979' 2014-07-18 11:20:20.203 Core Garbage collected 0 objects for session cf2d3928-c2a0-41bf-adb5-91654585671c 2014-07-18 11:20:20.387 Core Object with id '[MendixIdentifier:: id=43347146414534661 objectType=XXXXX.XX entityID=123]' could not be retrieved. 2014-07-18 11:20:20.387 Core Creating system session '03f420b1-68d8-44d4-a10e-4d2a5357cfbc' 2014-07-18 11:20:20.390 Core Garbage collected 0 objects for session cf2d3928-c2a0-41bf-adb5-91654585671c 20140722 More info: Issue seems to be more generic, I cannot save any data regardless whether the object is microflow created or not (also when using the standard save buttons). Upgraded to 485 and it makes no difference. Also tested with a more recent client java version, no difference, created a test project in 485 and cannot reproduce the issue. Logged a call at mendix support. Will check some more and update this call if I find more relevant info. I have seen other forum posts but did not find a solution (other than just wait for it to resolve itself). ROOT CAUSE: We use Apache Tika for document content extraction, the tika-1.4-app.jar (in the userlib directory) caused conflicts with the application. Thanks Mendix support (Bart) for your assistance. Thanks.
Just this warning doesn't really tell you much right away. The first thing to do is to figure out where it is attempting to retrieve this object (some data view, some microflow, etc.) and then try to determine if it's really not there and why the application seems to think it should be there. You can find out what possible ways there are for that object to be deleted and see if it makes sense that one of them was triggered.
Edit: If this is on creation of an object in a microflow, maybe you could try to set the 'Core' log node to trace and see if the object that was just created accidentally gets garbage collected. Can you also give some more information on your application specifics, for example if persistent sessions are enabled and what database you're using?
Sebastiaan van den Broek
We had a similair problem with this. We also used a process where the user was guided through a couple of steps. Each step is a form. So the user can press back to go to form 1, press next to go to form 2 and a cancel button. The problem would arise with the cancel button. Because here we would open a new form where the user could choose to save the object before leaving, return to the object or delete the object. When the user choose delete we would see the same error that the object could not be retrieved.
My conclusions where that this error was generated because we did not close a form where this object was used. We choose not to close the form with this object before opening the cancel form because if the user would like to return to the object we would never know from which form the user would come since we have a lot of these type of forms.
I am still not sure if the error should be given though. At the other hand how would Mendix know that the form could be garbage collected?