Repository navigation
compile can strand the session: Unity stalls with isCompiling=true or wedges its main thread, holding single-flight until editor restart #2320
Description
Summary
During a usability-feedback round (2026-08-21, package revision ef737ee, uloop 3.0.0-beta.32, Unity 6000.3.15f1, macOS), one tester project hit two distinct compile hangs in a single session. Both left the compile request unanswered and single-flight rejecting every other command; the only recovery was restarting the editor. The tester lost the whole verification session (0 hot-reload runs, 0 pause-point runs).
Hang mode 1: build succeeds, pipeline never finishes (isCompiling=true stall)
Timeline (Unity-side vibe log; request compile_*_9bbe9ff5):
compile_request_received/compile_request_registered_for_status_pollingat T+0.- Editor.log shows the Bee build reached
*** Tundra build success(only CS0618 warnings for obsoleteRigidbody2D.velocity), then the API Updater ran ([ApiUpdater] ... Files: 1 modified), then nothing — no domain reload, no further compile pipeline output. - No
compile_finish_callback_received, no watchdog warning (compile_start_timeout/compile_finish_callback_missing/compile_aborted) was ever logged. - Status polls kept answering
is_compiling: truefor the rest of the session (10+ minutes).
Why the watchdog missed it: CompileLifecycleWatchdog treats EditorApplication.isCompiling == true as healthy progress and waits indefinitely; its two timeouts only cover "never started" (5s) and "stopped without callback" (2s grace after isCompiling goes false). A pipeline that stalls while still reporting isCompiling=true is outside both.
Suspected trigger: the API Updater run (obsolete-API rewrite) between build success and assembly reload; possibly a consent/modal path in a backgrounded editor. Not yet reproduced deterministically — a plain no-change compile on the same project succeeded in 7s afterward.
Hang mode 2: editor main thread wedges right after RequestScriptCompilation
Same session after an editor restart (request compile_*_8bfc7d84):
compile_request_received/registeredlogged, one last status poll answered 0.4s later, then the Unity-side IPC went completely silent — no further vibe log entries of any kind until shutdown.- Editor.log ends at
[ScriptCompilation] Requested script compilation because: Requested through public api— no build ever started. - Because the main thread was wedged, neither the watchdog nor the busy gate could respond; even
control-play-mode --action Statusgot no answer. - Context: the only change since the previous successful compile was scene mutation (objects placed via execute-dynamic-code); there were no script changes pending.
Root cause unknown. This issue tracks the investigation.
What bounds the damage today
- The CLI compile poll loop has a 10-minute deadline (
compileWaitTimeout), confirmed live: the stranded CLI process stopped polling exactly 10 minutes after its request. So the CLI side is not an infinite hang — but 10 minutes of silent, full single-flight lockout with no interim diagnostics reads as infinite to an agent, and the Unity side stays stuck (mode 1: isCompiling=true forever; mode 2: wedged) untiluloop launch -r.
Hardening planned (separate PRs)
- Unity-side watchdog escalation for mode 1: when assembly compilation results have been received but
compilationFinisheddoes not arrive within a generous no-progress deadline whileisCompilingstays true, abort with an indeterminate result naming the possible modal-dialog cause and theuloop launch -rrecovery. - CLI-side interim diagnostics during the compile wait: periodic stderr progress notes (elapsed, Unity-reported
is_compiling), and an explicit note when status polls stop being answered (editor likely wedged; suggest restart). - Busy rejections name how long the running command has been holding single-flight, so a stuck holder is distinguishable from a slow one.
Evidence (Editor.log copies for both hangs, vibe-log excerpts) is preserved by the reporter; timestamps above are from unity_vibe logs (note: vibe log filenames use the UTC date).
Activity
hatayama commentedon Aug 20, 2026
Hardening for both hang modes landed on v3-beta (diagnostics and escape guidance only — no behavior change to compile itself):
compile_assembly_progress_stalledwarning vibe log when the assembly-finished counter stops advancing for 5 minutes whileisCompilingstays true, plus acompile_assembly_finished_callback_receivedinfo log per callback. The next mode-1 occurrence will show whether the C#assemblyCompilationFinishedevents fire at all.is_compiling=truepipeline.Escalating to any automatic abort remains blocked on additional evidence from this issue: assembly progress that pauses legitimately (large second assembly, post-build processing) is indistinguishable from the stall on the Unity side, and a hard cap would also break the pending-record attach flow for legitimately long compiles.
Root-cause investigation stays open. The strongest current lead for mode 1 is the API Updater correlation (obsolete
Rigidbody2D.velocityusage;Files: 1 modifiedimmediately before the stall).hatayama commentedon Aug 20, 2026
Likely root cause: modal Script Updating Consent dialog
Reading the Unity Editor source (UnityCsReference) strongly supports a concrete mechanism for the Round 8 hangs:
Rigidbody2D.velocity),UnityScriptUpdaterConsentAPI.AskForruns. In an interactively launched Editor it shows a modal dialog viaEditorUtility.DisplayDialogComplex("Script Updating Consent", ...)(Editor/Mono/Scripting/ScriptCompilation/BeeDriver/UnityScriptUpdaterConsentAPI.cs).uloop launchstarts the Editor interactively with neither, so none apply.This matches all Round 8 observations: correlation with obsolete-API usage and API Updater activity right before the stall, indefinite hang, and zero recurrence in Round 9 where no tester touched an obsolete API.
Not yet verified directly (no screenshot/Editor.log of the dialog survives from Round 8; logs rotated). Cheap repro: add an obsolete-API script to a scratch project, run
uloop compile, and capture the screen with the OS tool when it stalls (uloopscreenshot would block on the same modal).Candidate fixes
-accept-apiupdatefromuloop launch— command-line consent skips the dialog and the updater rewrites files silently; the CLI should disclose the rewrite in the compile response.Direction (1 vs 2) needs a product decision; deferring the fix proposal until the current Round 9 fix round lands.
hatayama commentedon Aug 21, 2026
Resolved by the two PRs planned for this issue:
The separate 'API Update Required' dialog is intentionally not suppressed; it is covered by the improved stall warning only.