extension_list.cfg in .godot folder is deleted when opening a project

[cslfrd]

Tested versions

• Reproducible in: v4.4.dev3.official [f4af820]
• Not reproducible in: v4.4.dev2

System information

Godot v4.4.dev3 - macOS 14.5.0 - Multi-window, 1 monitor - Metal (Forward+) - integrated Apple M1 (Apple7) - Apple M1 (8 threads)

Issue description

When opening a project that has a GDExtension addon, the extension_list.cfg file in the .godot folder is deleted.

If running the project, it will throw errors if the addon is referenced in a script. The deletion of the extension_list.cfg file only happens every other time the project is opened. If the project is closed and opened again, the extension_list.cfg file is generated, and the addon works as expected. If the project is closed, and then opened again, the extension_list.cfg file is once again deleted. This can be consistently reproduced, where every even session recreates the config file and every odd session deletes it.

When opening the project in a session that deletes the extension_list.cfg file, it also throws the following errors and warning when the editor is opened:

Steps to reproduce

1. Create a new project in 4.4-dev3
2. Open the AssetLib
3. Download and install a GDExtension addon (in this case I tried with Debug Draw 3D 4.1.4+)
4. Save the project and close Godot
5. Open the project again
6. Repeat closing and opening the project and observe the extension_list.cfg be deleted and generated

Minimal reproduction project (MRP)

extension-list-config-file.zip

[cslfrd]

Further testing shows that commenting out the line compatibility_minimum = "4.1.4" from the .gdextension file stops this behaviour from happening. I'm unsure if this means this is a plugin specific problem, or a problem with the editor scanning/loading GDExtensions.

EDIT: Testing again, it stops the deleting/regenerating behaviour from happening, but throws an error and fails to load the GDExtension:

core/extension/gdextension_library_loader.cpp:299 - GDExtension configuration file must contain a "configuration/compatibility_minimum" key: res://addons/debug_draw_3d/debug_draw_3d.gdextension
Can't open GDExtension dynamic library: res://addons/debug_draw_3d/debug_draw_3d.gdextension

[cslfrd]

Tested again with a randomly picked GDExtension from the AssetLib (Lua GDExtension) and can reproduce consistently as described in the original comment, also producing the exact same errors and warning.

[cslfrd]

Could it be related to #97532, where it might mistakenly mark an extension as removed (and then deleting the line from extension_list.cfg)? That's the only PR from the changelog for 4.4-dev3 that I can make sense of would lead to the behaviour described in the issue.

[NetroScript]

I also have the same problem for my project on v4.4.dev3.official, which did not occur in v4.4.dev2.

It however seems unrelated to #97532 -> I compiled the engine on commit f4af820 only reverting the changes in the core/extension/gdextension_manager.cpp file of the mentioned PR, and the issue still remained.

[NetroScript]

Ok, I debugged the editor loading and identified the issue. I am not certain why the alternating pattern exists, however this regression was caused by #95678 , specifically an optimization exiting early when the loaded file is not a script file (see here and expand editor/editor_file_system.cpp causing the insertion of the GDExtension to be missed.)

So either this optimization needs to be reverted, or before that check, there would need to be an explicit check for gdextension as extension (or better explicitly calling the get_resource_type of GDExtensionResourceLoader, however I dont know if there might be a case where it is not available), in which case it can be inserted before checking then whether the file is a script.

If you tell me how exactly you would want to solve it, I would also be up for doing a PR for it.

[FireCatMagic]

Ok, I debugged the editor loading and identified the issue. I am not certain why the alternating pattern exists, however this regression was caused by #95678 , specifically an optimization exiting early when the loaded file is not a script file (see here and expand editor/editor_file_system.cpp causing the insertion of the GDExtension to be missed.)

So either this optimization needs to be reverted, or before that check, there would need to be an explicit check for gdextension as extension (or better explicitly calling the get_resource_type of GDExtensionResourceLoader, however I dont know if there might be a case where it is not available), in which case it can be inserted before checking then whether the file is a script.

If you tell me how exactly you would want to solve it, I would also be up for doing a PR for it.

My opinion is without merit as I have never directly opened a PR for godot before but it seems like an explicit check is what would be best, as it would keep the optimizations from the PR but fix the GDExtension issue?
I'd implement it in which of the ways to you is the least bandaid of a fix, and if the code reviewers think it's fine then it's all good

[Hilderin]

@NetroScript
I think your approach to use ResourceLoader::get_recognized_extensions_for_type is the right one. It's sounds like a bug to me that the method returns .res and .tres. I'm not an expert of the GDExtensions but I'm pretty sure .res and .tres are not supported for GDExtensions. If you check into GDExtensionLibraryLoader::parse_gdextension_file, it only supports a ConfigFile format and not a resource file. It does not seems easy to modify ResourceLoader::get_recognized_extensions_for_type to not return .res and .tres for GDExtension and I'm worry about side effects so I think that excluding .res and .tres extensions in _first_scan_filesystem seems the right way to me.

I just created a PR based on your modifications with some optimizations to reload the file extensions list and some code reorganizing. Also, I added you as CoAuthor!