Resource silently fails to load with specific combination of @export/preload/globals/script references #110394
Description
Tested versions
- Reproducible in v4.4.1.stable.official [49a5bc7] and v4.5.rc1.official [08e9e6b29]
System information
Godot v4.4.1.stable - Windows 10 (build 19045) - Multi-window, 2 monitors - OpenGL 3 (Compatibility) - NVIDIA GeForce RTX 2080 (NVIDIA; 32.0.15.7283) - Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz (8 threads)
Issue description
With a very specific set of Resource subclasses, use of preload, globals, scenes, and references in script, a custom resource value assigned to an @export variable will silently fail to load (and instead simply be null) when the game is run in editor. No modification to the scene or files occurs and the assigned value is still correctly set when returning to the editor.
Crucially, the specific arrangement of classes, scenes, scripts, etc that are present all seem to be necessary to trigger this bug. If you remove any part of the MRP, the bug behaviour goes away and the resource loads correctly. I do mean any part of the MRP. It can be using a class name in print statement. It can be the order of globals loading. It can be removing an unused argument or the empty resource subclass. There is a chain established that during parsing, if done in a specific order, reaches a class that has a preload() call for a scene, which itself includes an instance of the original scene.
That sounds like a cyclic reference in scenes/resources but I don't see anything structurally wrong with it. Resources do not appear to have cyclic references, nor do scenes. The scripts certainly do refer to each other in a cyclical way, which seems to be causing an issue when the preload() is hit.
This is similar to #95909 in that I have again stumbled on to some architecture that elicits a failure to load custom Resources. However, this issue does not have any console output or errors at any time, nor does it delete any data.
Steps to reproduce
Run the MRP to see the specific, fragile structure needed to elicit the bug.
When you run the main scene ("my_class.tscn"), you will see it hits an assert as the Resource loaded is null (incorrectly). If you change any part of the project, the resource will load correctly.
Here is an example showing the resource failing to load, followed by making an innocuous change and the resource loading correctly: