Opening project in editor fails with "Parse Error: Busy."
Tested versions
- Reproducible in: v4.3.stable.official [77dcf97d8]
System information
Godot v4.3.stable - Windows 10.0.22631 - Vulkan (Forward+) - integrated Intel(R) UHD Graphics (Intel Corporation; 31.0.101.4887) - 13th Gen Intel(R) Core(TM) i5-1345U (12 Threads)
Issue description
The first time a project is opened in an editor (or after the .godot directory is removed), importing the scenes/scripts fails with:
ERROR: Parse Error: Busy. [Resource file res://thing.tscn:6]
at: _parse_node_tag (scene/resources/resource_format_text.cpp:289)
ERROR: Failed loading resource: res://thing.tscn. Make sure resources have been imported by opening the project in the editor at least once.
at: _load (core/io/resource_loader.cpp:283)
Closing and opening the same project a second time fixes the issue. The issue appears again if .godot directory is removed.
Steps to reproduce
- Download and unzip the attached sample project.
- Make sure the project is not open in the Godot editor.
rm -rf .godotgodot --editor --verbose --headless --import --quit- (Or open the project in the editor.)
- Observe the mentioned error in the output.
Minimal reproduction project (MRP)
At first sight, the issue seems to be caused by thing.gd being loaded first, it has a static typing reference to world.gd so Godot tries to load that, world.gd has a preload of thing.tscn so Godot also goes and loads that, and thing.tscn has a reference to thing.gd, at which point Godot likely refuses to try to load that because it is already being loaded.
Interestingly, if I only rename thing.gd to zthing.gd which presumably changes the import order, the project loads successfully and I see no errors.
The issue is primarily cosmetic, but it was causing issues in our CI pipeline which automates the import process (among other steps) and the error was breaking it.
This is the code that currently reports the error:
if (error) {
if (error == ERR_FILE_MISSING_DEPENDENCIES) {
// Resource loading error, just skip it.
} else if (error != ERR_FILE_EOF) {
ERR_PRINT(vformat("Parse Error: %s. [Resource file %s:%d]", error_names[error], res_path, lines));
return Ref<PackedScene>();
} else {
error = OK;
return packed_scene;
}
}
Although I don't understand the full context, it is possible that this case should be handled by the ERR_FILE_MISSING_DEPENDENCIES branch and the error should just be suppressed. But the error code that is returned in this case (ERR_BUSY) does not match the expected value.
I just experienced exactly same error. And I'm working on .NET build.
I found out it's caused by a cyclic reference between two scenes (via exported PackedScene property).
The output does not tell me it's a cyclic reference, giving me Parse Error: Busy instead.
I just experienced exactly same error. And I'm working on .NET build.
I found out it's caused by a cyclic reference between two scenes (via exported
PackedSceneproperty).The output does not tell me it's a cyclic reference, giving me
Parse Error: Busyinstead.
Same problem and observation here.
I am trying to create portals between two scenes, and my portal export an PackedScene targetScene and they are set to each other. This leads to resource loading failure (saying my scene1.tscn does not exists) if I start the game, and once I restart godot I am unable to even edit these two scenes. Clicking on them will result in "Missing dependencies" and clicking Open Anyway leads to Error while loading file 'Scene1.tscn' and the console prints many Parse Error: Busy.
This bug is critical, that I have to fix it by directly editing the .tscn file and remove cyclic reference. Without version control, it may corrupt the whole scene.
Cyclic references are not supported as you just discovered
Cyclic references are not supported as you just discovered
I assume this means cyclic references between scenes as described in @ShiratsuYudachi's comment, right? The original reported issue does not involve just scenes (and does not involve exported variables at all), one of the parts of the "cycle" there is caused by a type hint in a script.
I also found some discussion in #85501 which mentions the following:
Being resources, scenes don't support cyclic references, [ ... ] (unlike with scripts, where this should be fine, because
get_shallow_script()is designed to deal with the cyclic reference problem).
Yep I was referring to @ShiratsuYudachi
Exactly the same error and situation as @ShiratsuYudachi , I can't edit both scenes anymore
Just wanted to make an account and comment that I found a way to fix my two scenes to make them open-able and salvage my project. I opened up the TSCN file for both scenes in Notepad. I then deleted the "[ext_resource type=“PackedScene”.." lines with the TSCN scene reference that was causing a load error. I deleted the reference in my Portal line below that which had the TSCN as the next level. Doing this in both TSCN files allowed me to open then in the editor again. I need to find a new way of making a portal work between the two scenes for the player to go back and forth. Hope this helps.
We have now additionally started hitting this error when running godot --headless --verbose --export-release "Windows Desktop" something.exe and in this instance it does not help to run the import first or to rerun the command (i.e. the workaround suggested in the error message, to "Make sure resources have been imported by opening the project in the editor at least once", is not effective). Presumably in some cases the export code tries to reimport resources even though they were already imported. I have tried to look into the Godot source code, but couldn't find a clear cause.
We are now unable to run the export command without getting errors, which in my eyes raises the severity of this issue somewhat.
I was able to reproduce using the MRP, including converting the project to use the new resource UIDs and then deleting the .godot directory.
System information: Godot v4.4.1.stable (4d7c448a0) - Ubuntu 24.04.2 LTS 24.04 on X11 - X11 display driver, Multi-window, 1 monitor - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1080 (nvidia; 550.120) - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz (8 threads)
cc: @AThousandShips
Happened to me today, it happened to me due to cyclic reference in PackedScene exported variable of a shared instantiated node.
I have the same issue
In my case, this was also caused by cyclic referencing, but involving an autoload as part of the cycle.
I also get this cyclical issue (tested in 4.4 and 4.5) with two "room" scenes and a door object in each room that links to the connecting room using an exported packed scene. It's been a year since this was brought up, so I guess this isn't getting fixed and the workaround is to use a string path to the scene instead?
Attached a very simple MRP to reproduce this. Literally just have an exported PackedScene var and in two scenes link them to each other.