Small addition that I noticed as I’m trying out different things to identify a fix. I’m also noticing that each time I deploy a small change the Build fails. The Build Output from the dev portal unfortunately doesn’t tell me much (seems to only show a partial log):

But if I click “Publish” a second time after the failure from Studio Pro it seems to build. But that might also be a hint towards what’s going wrong?

Well the build failures seem to be unrelated, I recently saw this in the runtime logs when triggering a “Publish”: 

Failed to stage build: insufficient resources: memory

So most likely that’s just due to a lack of memory on the running node.

Still no closer to solving my issue, but the weird thing I have found is that I am able to load a ListView with some of the entity data if I use an older microflow that was also returning this entity. The strange thing is that if I copy that exact microflow in a new microflow, it doesn’t work...

I’m pretty dumbfounded. This just seems like a very strange bug.

I’ve been able to export the backup and examine the mendixsystem$entityidentifier and mendixsystem$entity data. There is no object with entity ID 18. The entity actually has the ID 30.

I also

I also wrote a simple java action that pulls the short ID of an object:

import com.mendix.systemwideinterfaces.core.IContext;
import com.mendix.webui.CustomJavaAction;
import com.mendix.systemwideinterfaces.core.IMendixObject;
import com.mendix.systemwideinterfaces.core.meta.IMetaObject;

public class GetMetaObjectShortId extends CustomJavaAction<java.lang.Long>
{
	private IMendixObject ObjectToGetShortId;

	public GetMetaObjectShortId(IContext context, IMendixObject ObjectToGetShortId)
	{
		super(context);
		this.ObjectToGetShortId = ObjectToGetShortId;
	}

	@java.lang.Override
	public java.lang.Long executeAction() throws Exception
	{
		// BEGIN USER CODE
		IMetaObject MetaObject = this.ObjectToGetShortId.getMetaObject();
		long ShortToReturn = (long)MetaObject.getId();

		return ShortToReturn;
		// END USER CODE
	}

	/**
	 * Returns a string representation of this action
	 */
	@java.lang.Override
	public java.lang.String toString()
	{
		return "GetMetaObjectShortId";
	}

	// BEGIN EXTRA CODE
	// END EXTRA CODE
}

I’ve used this in the retrieve microflow that works for loading the entity in ListViews. It returns the ShortId 30, which in the backup that I pulled corresponds to the correct entity.

So why is it that ListViews are trying to execute an XPath query to an entity with the ID 18?

For anyone reading this and dealing with the same issue. Unfortunately I was not able to fix it. I did figure out a little more that it was most likely the same thing that Thijs was facing in his forum post here: https://forum.mendix.com/link/questions/8943

I saw in the underlying data that there were objects that had different short-ids. Which I couldn’t really figure out how to fix. At first I tried deleting the objects with the ‘missing’ id. Which fixed my issue for loading data in the List Views. But I later had issues with editing new objects of the same entity, with the same error message, which leads me to believe that the mixed ID was also still being used somewhere else. 

Instead of spending more time on this bug I decided it was best to unlink my sandbox and start with a fresh database.

Unfortunate that a major version upgrade leads to issues like this, but not entirely sure what I could have done to prevent it or resolve the issue.