Object of type Monitor.Monitor with guid 76842668646456325 cannot be updated, as it does not exist anymore

3
Hello all, I have a microflow which processes a large batch of data (this takes 6+ hours) . At the start of the microflow I create a 'Monitor' object. This object is used for logging. At the end of the microflow all data including the Monitor object is updated and commited and I encounter this message: Error occured while executing the process, error:com.mendix.core.CoreRuntimeException: com.mendix.systemwideinterfaces.MendixRuntimeException: com.mendix.systemwideinterfaces.core.UserException: Object of type 'Monitor.Monitor' with guid '76842668646456325' cannot be updated, as it does not exist anymore When debugging the microflow, the monitor object is available at all steps. Any help is appreciated!
asked
4 answers
4

I encountered the same error; in this case it was caused by the fact that the object had been deleted while iterating over its list.

Even though the object itself was deleted, it was not deleted from the list. At debugging the object was still visible. When later in the process this object was referred to again from this list it could not be found in the database, resulting in this error. It was solved when the object was removed from the list before it was deleted.

answered
2

I had faced a similar issue. My problem was that I had created the ‘LogLine’ entity at the start of the flow, and then later in the middle of the flow, I had an action with custom error handling with rollback. I had wanted to capture the latestError in the LogLine entity, but since the entity was created during the flow, the rollback had deleted this entity, which meant that it doesn’t exist any more.

 

To fix this issue, I would need to change the error handling to not have rollback.

I possibly could do some tricks involving creating the LogLevel entity in a separate transaction, so that when the rollback happens, the LogLevel still persists, but I didn’t actually try this out.

answered
1

I think it is possible that because of the object monitor is not committed yet the object will be deleted because of the long duration of the microflow.


It might be smart to look for ways to shorten the microflow time. You could also for example start the microflow with a create of monitor and commit this. Then create a sub micrflow that does the processing in batches, start up this sub micrflow in background with the java action from community commons. This way the microflow is run in background and in batches and you monitor object is always accessible.

answered
0

Though Maarten's answer is correct and I would advise his answer it is still strange that the object is not there anymore. The object would only be removed if there are no processes using this object and that seems not to be the case. So I would also double check the delete behaviour of references to this object to see if this object is not accidently removed by some other proces.

Regards,

Ronald

answered