fix: uloop compile returns as soon as the Editor answers instead of warming execute-dynamic-code first

[hatayama]

Summary

• uloop compile now returns as soon as the Editor answers with the compile result. It no longer sends a readiness probe (get-version, then execute-dynamic-code) after a successful compile, so the Warming execute-dynamic-code after compile... spinner and the warning: post-compile warmup skipped: ... line are gone.

Why

• The post-compile warm-up was only an advance payment for a following execute-dynamic-code. When the next command was hot-reload, run-tests, or get-logs, the time was wasted.
• On a large project it took about 6.5 seconds per compile (the first probe timed out after 5 seconds, the second succeeded). For that whole time it held the Editor's single-flight slot, so uloop compile finished later and a hot-reload sent meanwhile had to wait for it as well.
• The Editor keeps its own warm-up for the first execute-dynamic-code after startup or a domain reload, so dropping the CLI one does not break anything. The cold start moves to the next execute-dynamic-code (about 5 seconds on the reporting project).

Behaviour change

Compile result	Editor readiness	Where the result came from	Before	After
Success: true	probe answers	fresh compile	A probe ran before the result was returned (about 1 to 7 seconds), holding the Editor's slot	The result is returned as it is; nothing more is sent
Success: true	probe times out	fresh compile	Waited up to 180 seconds, then warning: post-compile warmup skipped, exit 0	Same as above, no warning
Success: true	either	attached wait or stored result	Same as the two rows above	Same as above
Success: false	—	any	No warm-up	Unchanged
unreadable	—	any	No warm-up	Unchanged

Changes

• The compile result is turned into the command result with no request after it. The warm-up, its warning, and the result-status helper that only decided whether to warm up are removed.
• Tests that cancelled the command at a successful answer, only to avoid the 180-second probe, now run to completion. One of them, and two new ones, assert that a successful compile returns in under 30 seconds.
• New tests cover a successful stored result and a successful attached wait. These two attach paths had no success case before.
• The shared compile-status contract test now checks that the fixture's Result reads as a successful compile through the same exit-code logic the CLI uses.
• Comments that explained Success:false fixtures as a way to avoid the warm-up are updated.

Verification

Run in cli/project-runner:

• gofmt -l . — no output; go vet ./... — clean; golangci-lint run ./... — 0 issues; golangci-lint run -c ../.golangci-complexity.yml ./... — 0 issues.
• go test ./... -count=1 — everything passes except TestSendWithTransientConnectionRetryAbortsOnRefusedConnect, which cannot bind a Unix socket inside the sandboxed shell used for this change (bind: operation not permitted) and does not touch this code. With that one test skipped, the module reports ok.
• Coverage (/cmd/ excluded, as in the baseline): 95.5%, against a baseline of 95.2%.
• scripts/check-file-length.sh at the repository root: no findings.
• Red before the change (-timeout 300s): the lost-request pause-point test and the two new attach tests each failed after 180 s on the under-30s assert (took 3m0.02s after a successful answer). The busy-rejection test, with two subtests at 180 s each, hit the 5-minute test timeout.
• Mutations, applied after committing and reverted afterwards:

Mutation	Result
A readiness wait put back before the result is returned	Caught: the three under-30s tests fail after 180 s
The result always returned with exit code 1	Caught: 6 tests fail (the direct unit test, three pause-point recovery tests, and the two attach tests)
spinner.Stop() removed	Not caught: no test observes the spinner

• Checking against a live Editor was skipped: no Editor had this checkout open.

This pull request targets an integration branch, so build-and-test does not run on it; the checks above were run locally.

Not changed

• The readiness wait used by launch and by execute-dynamic-code while it waits out a domain reload.
• cli/common (the shared readiness helper stays) and the Editor-side warm-up.

[coderabbitai]

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration

• Configuration used: Repository: hatayama/unity-cli-loop/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 9d4ff9d9-94d6-4106-a304-d6f74602684b

📥 Commits

Reviewing files that changed from the base of the PR and between 35084a8 and 0c1004b.

📒 Files selected for processing (9)

• cli/project-runner/internal/projectrunner/compile_attach.go
• cli/project-runner/internal/projectrunner/compile_attach_test.go
• cli/project-runner/internal/projectrunner/compile_current_sources_test.go
• cli/project-runner/internal/projectrunner/compile_fresh_recovery_test.go
• cli/project-runner/internal/projectrunner/compile_status_response_contract_test.go
• cli/project-runner/internal/projectrunner/compile_wait_test.go
• cli/project-runner/internal/projectrunner/pause_point_release_recovery_test.go
• cli/project-runner/internal/projectrunner/run.go
• cli/project-runner/internal/projectrunner/run_test.go

 ___________________________________
< This function is pure-pure chaos. >
 -----------------------------------
  \
   \   (\__/)
       (•ㅅ•)
       / 　 づ

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}