Hey folks, apologies for the slow response time. We’re almost caught up on EPS cases again so this will improve.
Having read up on the thread, Luke if I understand your finding correctly by commenting out the condition
if (!bAlreadyResolvingExport || GetLoaderType() != ELoaderType::ZenLoader)which causes ForceRegenerateClass to be called, you no longer run into the ensure? So for the asset that trips the ensure ForceRegenerateClass() was called in 5.5, but is skipped in 5.6, is that right?
Since you’ve already spent time comparing 5.5 and 5.6 behavior, would you mind sharing the 5.5 and 5.6 callstacks of when FLinkerLoad::DeferExportCreation is entered, as well as when in 5.6 the bCustomPropertyListForPostConstructionInitialized ensure fails?
For the folks from other studios running into the failing ensure, can you also share the callstack of the failing ensure?
So far, I believe the issue is triggered by the presence of cyclical dependencies. If the callstack contains calls to LoadPackageInternal, please annotate it with which asset is being loaded (anonymize if needed, like BP_SomeParentClassA, etc). That will give valuable info despite not being able to isolate this into a small repro project. I’ll collect some more data and then pass on to a suitable engine dev. Thanks everyone!