COMPILE_WAIT_TIMEOUT is unconfigurable and its documented recovery is refused as UNITY_SERVER_BUSY #2032

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

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:

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

1. 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.
2. 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.
3. 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