Settle four seconds after the first scan before opening a scene - #1089
Merged
Merged
Conversation
With a GODOT_BIN that cannot be started, runtime_launch answered success: false and exit_code 0, the shape of a game that ran and failed, and said to put godot on PATH whatever GODOT_BIN named. The other tools that start their own Godot answer 503 engine_unavailable since #1045. The test runner now records a spawn Windows refused, and the handler refuses that, or a POSIX child that exits 127, the same way.
scene_create, scene_pack_branch and viewport_create_test_lab with overwrite: true rebuild a tab that holds the scene they replace, whatever it holds, and the answer said only editor_scene_reloaded: true. An edit someone had open in that tab was thrown away with nothing naming it. The bridge reads the unsaved list before the rebuild, and the answer now carries editor_scene_discarded_unsaved: true or false on Godot 4.7, and null before it, where the engine cannot say.
On a runner with no Godot, runtime_launch now answers 503 engine_unavailable, and the engine identity test expected a success body with the engine fields. Nothing runs there, so the refusal is the answer; the test now checks it names the engine it tried.
editor_undo, editor_redo, scene_call_method and a delivered signal_emit said nothing about the saved state, so no save step followed them, and their follow-up entries were exempt under #1049. A history step can land back on the saved version as well as move off it, and project code can change anything. On Godot 4.7 their answers now read the edited scene against the unsaved list and carry scene_saved, which the existing rule turns into a save step when it is false. Before 4.7 they carry a limitation saying the engine cannot tell. The four move from exempt to leaves: ["save"].
The hold from #1069 released scene_open on the frame after the editor applied its first scan. That scan also starts the editor script documentation threads, and a scene opened then can crash the editor on a Godot bug (#285, godotengine/godot#123273). The new startup test hit it on CI 4.6.2 twice in five runs: ILLEGAL_INSTRUCTION on a worker thread, with the open still held. The hold now lasts four seconds past the scan, the settle the harness fixture smoke plugin has used for the same moment since #296.
github-actions
Bot
added
documentation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #1083, for #1069.
Stacked on #1088, #1087 and #1086. Their commits show here until they merge.
The hold #1083 added released
scene_openon the frame after the editor applied its first scan. That scan'ssources_changedalso starts the editor's script documentation threads, and a scene opened in the next frames can crash the editor on the Godot bug #285 tracks (godotengine/godot#123273): the thread that finishes the documentation joins the loader thread after a second regeneration on the main thread already has, and it traps. The new startup test met it on CI's 4.6.2 runner in two of five runs. With the editor's output now kept, the second one showsILLEGAL_INSTRUCTIONon a worker thread, with the open still held and no Didi frame on the stack.The hold now lasts four seconds past the first scan. That is the settle the harness fixture's smoke plugin has used for the same moment since #296, and the harness has been stable with it. Locally the startup test's open now waits about 7.5 s and passes on 4.5.1, 4.6.2 and 4.7.2.
Test:
EditorHook.SceneOpensWaitOutASettleAfterTheFirstScandrives the settle with a clock: held before the scan, held on the frame the scan is seen and three seconds later, released at four. It fails with the settle removed.Checked locally: native suite (959), Python suite, docs validator, test inventory, and the startup live test on all three lines. CHANGELOG updated under Unreleased, Fixed.