Blueprint dependency tracking issue causing asset fallback to chunk 0

Recompiling and resaving a Blueprint-compileable asset changes the EditorOnly vs Game classification of its hard dependencies on disk, flipping references that were wrongly tagged Hard, EditorOnly back to Hard, Game, which means an asset’s committed save can carry stale/incorrect dependency classifications that the editor reports as up-to-date. Those mis-classified-as-EditorOnly content refs cause runtime content (textures, fonts, materials) to leak into chunk0.

The classification is produced by FPackageHarvester during SavePackage, and an in-memory compile does not recompute it.

The Game/EditorOnly dependency classification is written by the harvester at save time. The AssetRegistry’s stored deps come from the last on-disk save. So an asset can show Status=UpToDate, compile-green, yet have wrong classifications frozen on disk.

It means that we effectively need to save and compile twice to fix the issue for sure.

The mis-classified path is legitimately a Game path so the harvester is genuinely wrong.

UWidgetBlueprintGeneratedClass.WidgetTree is DuplicateTransient (skips object duplication only) but is serialized and cooked into the runtime class. So the generated-class WidgetTree is a real Game path to the content refs. When the harvester tags those content refs EditorOnly, that is a genuine misclassification.

I believe the trigger is a reference mutation + save without a (correct) recompile.

It seems like an engine bug but here are a few questions so we can understand the issue better:

Why does FPackageHarvester classify a hard ref reachable through the generated-class WidgetTree (a cooked Game path) as Hard, EditorOnly after a reference mutation + save, when a subsequent recompile+save reclassifies it Hard, Game?

How does Epic prevent this internally? Is there a save-path recompile, a cook-time reharvest, or a validation step in Fortnite’s pipeline that catches stale dependency classifications before submit?

Is the correct durable fix to force a Blueprint recompile (regenerate the generated class) before the harvester runs during save?

[Attachment Removed]

I’m not sure that’s the same because i didn’t went into as much details like you, but in 5.7 my team did hit an editor only references issue as well, it was trigger by a blueprint save, but not beeing recompiled before the save, if that sounds like what you’re having, you could try this CL from ue5-main 50789595 (https://github.com/EpicGames/UnrealEngine/commit/719acea7d167c45b3e5ccfaca7488207f16d4b1f)

[Attachment Removed]

Hello,

The owner of this code recommends integrating both 50789595 and 50835672.

Regards,

Martin

[Attachment Removed]