fix: A request that Unity keeps answering busy no longer brings the Editor to the front

[hatayama]

Summary

• When Unity keeps answering server_busy because another command is running, the CLI no longer brings the Editor to the front after five seconds. It keeps resending once a second within the 10-second window and returns the BUSY error when the window runs out, as before.

Why

• The busy-stall focus was a rescue for a backgrounded Editor that macOS might have suspended, so that the running command could finish. ADR 0012 (fix: Commands no longer run several times slower while the Unity Editor stays in the background on macOS #3200) has the running command hold a macOS activity, so a busy Editor is a working Editor and bringing it to the front only moves the user's windows.
• The same rescue was already removed from hot reload (fix: Hot reload sent while another uloop command runs waits for it instead of failing as busy #3226) and from the compile start wait (fix: uloop compile no longer brings the Editor to the front while it waits for compilation to start #3228). This was the last place it remained, and removing it was decided by the maintainer.

Changes

• The bounded busy resend no longer tracks how long the busy answers have lasted and never calls the focus controller. The busy_stall focus reason, its threshold, and the override for tests are removed.
• The comments on returnBusyWithoutRetry and on the hot reload busy wait no longer mention the busy-stall focus.
• Tests:
  • The test that pinned one focus after persistent busy answers now pins that no focus and no restore happen (TestSendWithTransientConnectionRetryNeverFocusesWhileBusy).
  • The test that pinned the threshold against the retry window is removed.
  • Three focus controller tests used busy_stall only as an example reason; they now use pre_accept_timeout, including the expected reason in the vibe log.
• ADR 0012 records the change under Consequences.

Input space

Busy lasts	returnBusyWithoutRetry	Cancel	Before	After	Test
Clears within the window (< 5 s)	false	no	resends and returns the answer, no focus	same	TestSendWithTransientConnectionRetryRetriesBusyResponses
5 s or more, within the window	false	no	focuses at 5 s, keeps resending	no focus, keeps resending	TestSendWithTransientConnectionRetryNeverFocusesWhileBusy
Until the window runs out	false	no	returns the last busy as a BUSY error, no focus at the end	same	TestSendWithTransientConnectionRetryReturnsBusyAfterRetryWindow, ...KeepsBusyBoundedByBaseWindow
Busy, then a dispatched failure	false	no	returns that failure	same	TestSendWithTransientConnectionRetrySurfacesDispatchedFailureAfterBusy
First busy	true	no	returns the first busy without resending, no focus	same	TestSendWithTransientConnectionRetryReturnsTheFirstBusyAnswerWhenAsked
Any	any	yes	returns ctx.Err()	same	existing cancel tests (finishBusyRetry is unchanged)

Verification

Run in cli/project-runner:

• Red first: with the threshold override still in place, the inverted test failed with one focus call. After the removal it passes.
• gofmt -l .: empty. go vet ./...: clean. golangci-lint run ./...: 0 issues.
• go test ./... -count=1 -skip TestSendWithTransientConnectionRetryAbortsOnRefusedConnect: ok. The skipped test binds a Unix socket, which the local sandbox denies; it is unrelated to this change.
• Coverage of internal/projectrunner: 95.5% (baseline 95.2).
• scripts/check-file-length.sh: no findings.
• Mutations, applied to the committed code and reverted afterwards:

Mutation	Result
Call the focus with the busy_stall reason on every busy answer	Caught by TestSendWithTransientConnectionRetryNeverFocusesWhileBusy
Return the first busy answer instead of resending	Caught by TestSendWithTransientConnectionRetryRetriesBusyResponses
Focus with final_response_timeout when the busy window runs out	Caught by TestSendWithTransientConnectionRetryNeverFocusesWhileBusy

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

Not changed

• The busy resend, its 10-second window, and the BUSY error when the window runs out.
• returnBusyWithoutRetry, which hot reload uses.
• The other focus reasons: undispatched_connection_failure, pre_accept_timeout, main_thread_stall, heartbeat_silence_timeout, final_response_timeout.

[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: eece2e3e-8cf5-4db0-a74e-f154ecaaf708

📥 Commits

Reviewing files that changed from the base of the PR and between f3daae7 and 7f80161.

📒 Files selected for processing (4)

• cli/project-runner/internal/projectrunner/connection_retry.go
• cli/project-runner/internal/projectrunner/connection_retry_test.go
• cli/project-runner/internal/projectrunner/hot_reload_busy_wait.go
• docs/adr/0012-hold-a-macos-activity-while-a-command-runs.md

 ___________________________
< Goodbye, pre-merge panic. >
 ---------------------------
  \
   \   \
        \ /\
        ( )
      .( o ).

✨ 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.}