Skip to content

fix: use update_file() instead of full scan() on single-file writes (prevents EditorFileSystem global-class SIGABRT)#508

Merged
dsarno merged 1 commit into
mainfrom
fix/script-create-update-file
Jun 1, 2026
Merged

fix: use update_file() instead of full scan() on single-file writes (prevents EditorFileSystem global-class SIGABRT)#508
dsarno merged 1 commit into
mainfrom
fix/script-create-update-file

Conversation

@dsarno

@dsarno dsarno commented Jun 1, 2026

Copy link
Copy Markdown
Contributor

Problem

script_create, script_patch, and filesystem write_text each triggered a full recursive EditorInterface.get_resource_filesystem().scan() per write. Under concurrent file creation (multiple MCP clients, or a stress run), these scans stack — the editor re-enqueues the update_scripts_classes / update_script_paths_documentation WorkerThreadPool tasks while a previous scan is still pending:

ERROR: Task 'update_scripts_classes' already exists.
ERROR: Task 'update_script_paths_documentation' already exists.
ERROR: Condition "!tasks.has(p_task)" is true.

…leaving the global-class registry inconsistent. The next idle filesystem scan can then SIGABRT in ScriptServer::remove_global_class_by_path() — a hard editor crash:

SIGABRT → abort
  ScriptServer::remove_global_class_by_path(String const&)
  EditorFileSystem::_register_global_class_script(...)
  EditorFileSystem::_update_script_classes()
  EditorFileSystem::_update_scan_actions()
  EditorFileSystem::_notification(int)

Engine-side record of the underlying abort: dsarno/godot#6.

Fix

Switch all three sites to EditorFileSystem.update_file(path) — the single-file registration call the rest of the plugin already uses (material/theme handlers, filesystem reimport, resource_io). It registers just the written file without the recursive scan-action batch, so the duplicate-task race can't occur. It's also cheaper than a full project rescan per write.

Validation (concurrency stress harness)

full scan() (before) update_file() (after)
Task ... already exists / !tasks.has(p_task) 5 + 5 per run 0
SIGABRT intermittent (3 crash reports) none across heavier runs

🤖 Generated with Claude Code

script_create, script_patch, and filesystem write_text each triggered a full
recursive EditorInterface.get_resource_filesystem().scan() per write. Under
concurrent file creation (e.g. multiple MCP clients, or a stress run) these
scans stack: the editor re-enqueues the update_scripts_classes /
update_script_paths_documentation WorkerThreadPool tasks while a previous scan
is still pending, emitting "Task '...' already exists" / Condition
"!tasks.has(p_task)" is true, and the global-class registry is left
inconsistent. The next idle filesystem scan can then SIGABRT in
ScriptServer::remove_global_class_by_path() — a hard editor crash.

Switch all three sites to EditorFileSystem.update_file(path), the single-file
registration call the rest of the plugin already uses (material/theme handlers,
filesystem reimport, resource_io). It registers just the written file without
the recursive scan-action batch, so the duplicate-task race can't occur.

Validated with a concurrency stress harness:
- before (full scan): 5x "Task ... already exists" + 5x "!tasks.has(p_task)"
  per run, intermittently escalating to the SIGABRT (3 crash reports).
- after (update_file): 0 of those engine errors across heavier runs, no crash.
- create -> immediate attach still settles (import_settled=true), so the #261
  import-settle behaviour is preserved.
- GDScript script (38) + filesystem (16) suites pass; Python import-settle (6)
  + script/filesystem unit tests (67) pass.

Engine-side record of the underlying abort: dsarno/godot#6.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@codecov

codecov Bot commented Jun 1, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant