Hello,

We are unable to reproduce this issue. Can you please give some more details and especially a logfile created using CLI params -loglevel spam -persistence dig so we can see what exactly is spamming? The spawn request collects all known IDs and emits result callbacks for them immediately before sending a query to fetch additional data if there were not explicit includes given.

There may be a potential issue when sending an unconditional query into a collection, attempting to respawn instances already loaded, but this does not seem to fit the description of your issue.

This is what we tried:

class PersistenceRepro
{
	static void Do()
	{
		auto persistence = PersistenceSystem.GetInstance();

		PersistenceSpawnRequest request();
		request.Collection = persistence.FindCollection("Character");
		request.Include = {"01a018a9-d796-8886-8400-000000055a6e"};
		
		persistence.RequestSpawn(request, new PersistenceResultCallback(ReproCallback));
	}

	static void ReproCallback(EPersistenceStatusCode statusCode, Managed result, bool isLast)
	{
		PrintFormat("Callback invoked: %1, %2, %3", statusCode, result, isLast);
	}
}

Your snippet passes an explicit single-id Include, which works reliably for us too. Our failing requests set Collection with no Include list at all.

I'll capture a -loglevel spam -persistence dig log of both modes on 1.8.0.10 and attach it as soon as I get some time to look into it

When requesting an already existing instance like that it should fail with bad request at that point, and not continue for ever - unless your outer call logic then re-attempts it. Maybe you can prepare a small repro code snippet like I did to show us the problem.