Summary
compileWaitTimeout is a hard-coded 10-minute constant with no caller-side override, and the recovery its own comment describes does not work when the timeout is actually reached on a large project.
|
// Why 10m: worst-case blind block beats headroom. Why ≤ C# CompileResultLifetime (20m): |
|
// timed-out clients can still retrieve results by retrying uloop compile ~10m more. |
|
compileWaitTimeout = 10 * time.Minute |
// Why 10m: worst-case blind block beats headroom. Why <= C# CompileResultLifetime (20m):
// timed-out clients can still retrieve results by retrying uloop compile ~10m more.
compileWaitTimeout = 10 * time.Minute
The stated recovery is "retry uloop compile". In practice that retry is refused at dispatch with UNITY_SERVER_BUSY, because the compile that caused the timeout is still running inside Unity and uloop is single-flight. The CLI's built-in retry only covers 10 seconds, so a caller following the documented recovery gets an immediate failure instead of the result.
Reproduction
scripts/soak-loop.ps1 against three checkouts of the same large Unity project (Unity 6000.3.15f1, ~5-6 GB editor working set), run in parallel, 10 iterations each. All three runs lost the same iteration in the same way:
14:07:45 FAIL iter=10 compile-forced COMPILE_WAIT_TIMEOUT
"Compile status wait timed out after 600000ms."
14:09:28 FAIL iter=10 compile UNITY_SERVER_BUSY (busy running 'compile') <- the documented recovery
14:11:34 FAIL iter=10 get-logs UNITY_SERVER_BUSY
14:12:46 FAIL iter=10 get-hierarchy UNITY_SERVER_BUSY
14:13:31 FAIL iter=10 screenshot UNITY_SERVER_BUSY
14:13:48 FAIL iter=10 dynamic-code UNITY_SERVER_BUSY
14:14:08 FAIL iter=10 scene-ensure UNITY_SERVER_BUSY
14:14:33 FAIL iter=10 run-tests UNITY_SERVER_BUSY
Reproduced 3/3, so this is the load profile rather than a flake. The editor stayed busy for roughly seven more minutes after the timeout; every command in that window was refused.
Measured compile --force-recompile durations on that project:
| Condition |
Duration |
| Single soak, Release code optimization |
~390 s |
| Single soak, Debug code optimization |
~484 s |
| Three parallel soaks, Debug |
> 600 s (hits the timeout) |
A single-editor run already sits within ~2 minutes of the limit, so the usual multipliers - a bigger project, a slower machine, a loaded CI agent - push a legitimate compile past it.
Why this matters
The error text is careful to say the editor is not frozen:
Compile status wait timed out after 600000ms. This does not mean the Unity Editor is frozen; the compile may simply still be running.
But the caller is left with no working lever. It cannot ask for a longer wait, it cannot learn how much longer the compile will run, and the retry the design intends is rejected for as long as the compile continues. What is actually required today is a client-side backoff loop of several minutes against UNITY_SERVER_BUSY - which is not stated anywhere, and which every caller has to reinvent.
Suggested direction
- Make the wait configurable per invocation, e.g.
compile --compile-wait-timeout-seconds, defaulting to the current 10 minutes. This keeps the "worst-case blind block" default while giving large projects a way out.
- Make the documented recovery real: after
COMPILE_WAIT_TIMEOUT, either let a retried compile attach to the in-flight compile instead of being refused as busy, or say plainly in NextActions that the editor stays busy until the compile finishes and the retry needs a multi-minute backoff.
- Optionally include compile progress (elapsed time, assembly count) in the timeout response so a caller can decide whether waiting is worthwhile.
Environment
- uloop dispatcher 3.0.0-beta.24, project runner 3.0.0-beta.60, package 3.0.0-beta.66
- Unity 6000.3.15f1, Windows 11
Summary
compileWaitTimeoutis a hard-coded 10-minute constant with no caller-side override, and the recovery its own comment describes does not work when the timeout is actually reached on a large project.unity-cli-loop/cli/project-runner/internal/projectrunner/compile_wait.go
Lines 26 to 28 in 5aa4ac7
The stated recovery is "retry
uloop compile". In practice that retry is refused at dispatch withUNITY_SERVER_BUSY, because the compile that caused the timeout is still running inside Unity and uloop is single-flight. The CLI's built-in retry only covers 10 seconds, so a caller following the documented recovery gets an immediate failure instead of the result.Reproduction
scripts/soak-loop.ps1against three checkouts of the same large Unity project (Unity 6000.3.15f1, ~5-6 GB editor working set), run in parallel, 10 iterations each. All three runs lost the same iteration in the same way:Reproduced 3/3, so this is the load profile rather than a flake. The editor stayed busy for roughly seven more minutes after the timeout; every command in that window was refused.
Measured
compile --force-recompiledurations on that project:A single-editor run already sits within ~2 minutes of the limit, so the usual multipliers - a bigger project, a slower machine, a loaded CI agent - push a legitimate compile past it.
Why this matters
The error text is careful to say the editor is not frozen:
But the caller is left with no working lever. It cannot ask for a longer wait, it cannot learn how much longer the compile will run, and the retry the design intends is rejected for as long as the compile continues. What is actually required today is a client-side backoff loop of several minutes against
UNITY_SERVER_BUSY- which is not stated anywhere, and which every caller has to reinvent.Suggested direction
compile --compile-wait-timeout-seconds, defaulting to the current 10 minutes. This keeps the "worst-case blind block" default while giving large projects a way out.COMPILE_WAIT_TIMEOUT, either let a retriedcompileattach to the in-flight compile instead of being refused as busy, or say plainly inNextActionsthat the editor stays busy until the compile finishes and the retry needs a multi-minute backoff.Environment