Repository navigation
fix: Hot reload asks for a retry, not a compile, when the Editor was only busy compiling or importing - #3219
Merged
Conversation
…or was busy When Unity's own compile (auto refresh) overlaps a hot-reload request, the apply fails with "The Editor became busy", and the CLI then runs a fallback compile that ends the Play session and every live patch. A refusal whose only reason is a compile or an import in progress passes once the Editor settles, so the response now says so and names the files it selected, letting the CLI wait and apply the same files again in the same command. - RetryAfterEditorReady is true only when every failure is EditorNotReady; any other kind mixed in gives the same result after a wait. - SelectedFiles lists the run's scripts as project-relative asset paths, whether given as --files (kept as typed until now) or selected as the changed files, so the retry does not re-select an empty change set. - A request that arrives while the Editor is compiling or importing is refused when the file is resolved, before the transform, with a reason of its own. A file whose patches are active and unchanged is left alone, and every earlier, more specific refusal keeps its classification. A failed last compile is not treated as busy: waiting does not clear its errors.
The builder sets a failure kind only on a failed row, so a run with no failure always passes None, and None never equals EditorNotReady. The hasFailure argument therefore never changed the answer: removing it left every test passing.
…tput reference A reader of a refused apply needs to know that the CLI waits and applies the same files again, and that the retry sends them as an explicit list, so the default selection's leave-out does not apply on the second apply.
Contributor
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 17 minutes. View limit detailsLimit details: You’ve used all 4 included reviews currently available. Review configuration: ⚙️ Run configuration
⛔ Files ignored due to path filters (2)
📒 Files selected for processing (18)
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. Comment |
hatayama
merged commit Oct 7, 2026
9a271c5
into
feature/hot-reload-large-project-feedback-2
5 checks passed
hatayama
deleted the
feat/hot-reload-asks-for-a-retry-after-the-editor-settles
branch
October 7, 2026 09:00
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
RetryAfterEditorReady: true), so the CLI can wait for the Editor to settle and apply the same files again in the same command (the CLI side is the follow-up PR).SelectedFiles), so a retry can send exactly those files.Aim
This is not a speed promise. When Unity's own compile (auto refresh) overlaps a hot-reload request, most of the time is spent waiting for that compile either way. What the retry protects is the Play session and the patches that are live: today such a refusal falls through to the fallback compile, which ends both. And if Unity's compile already took the edit in, the second apply finishes in seconds with
NothingToApply, instead of a second, useless compile.User Impact
uloop hot-reloadright away often failed with "The Editor became busy before the reload could be applied: The Editor is compiling …". With--compile-on-skip auto, the CLI then ran a fallback compile; withoff, the reader had to wait and run the command again.Changes
RetryAfterEditorReadyis true only when the kinds of all failed rows add up to exactlyEditorNotReady. Any other kind mixed in leaves it false.AlreadyActive, because it has nothing to apply.SelectedFilesholds the run's scripts as project-relative asset paths.--filesentries were kept as typed until now (./Assets/A.cs, absolute paths). They are normalized here, so explicit files and the changed files the run selected read the same way.Fileslist. So the default selection's leave-out (a file that only adds enum members) does not apply on the second apply. This is accepted as a rare case.HotReloadApplyResponseBuilder.Buildtakes the selected files. Its test-only shim passes an empty list, because its callers hold a result but not the selection.output.mddocuments both fields.Behavior by input
RetryAfterEditorReadytrueRun_WhenTheEditorIsCompilingWhenTheRequestArrives_…Run_WhenTheEditorIsImportingWhenTheRequestArrives_…AlreadyActiveRun_WhenAnUnchangedAppliedFileArrivesWhileTheEditorIsCompiling_StaysAlreadyActiveRun_WhenTheEditorIsCompilingAtCommit_…Run_WhenTheLastCompileFailedAtCommit_…HotReloadNewSourceMembershipTests(unchanged)HotReloadPatchTargetSupport*Tests(unchanged)EditorNotReadyHotReloadEditorReadyRetryTestsVerification
uloop compile: 0 errors.uloop run-tests, run one regex at a time, all pass:HotReloadEditorReadyRetryTests,HotReloadEditorStateSnapshotTests,HotReloadBusyEditorResponseE2ETests,HotReloadDefaultFilesTests): 35 testsHotReloadPatchTargetSupportTests,HotReloadNewSourceMembership*,HotReloadRecommendedNextActionTests,HotReloadCompileFallbackDeciderTests,HotReloadApplyOutcomeTests,HotReloadPauseBeforeWiringWarningTestsandHotReloadIntroducedTypeResponseTests: 132 testsHotReloadToolTestsandHotReloadIntroducedTypeActivationTests: 132 testsscripts/check-file-length.sh(set to fail on findings): no findings. The CA1502 checker at 15: no findings.ResolvePatchTargetis at 14, with the refusal in a helper of its own.check-skill-size: noSKILL.mdover the limit.SKILL.mditself is not changed.Decideaccepts any set that containsEditorNotReadyDecide_WithEditorNotReadyAndDeclaration_IsFalse,Decide_WithEditorNotReadyAndCompiledAssemblyMissing_IsFalseGetBusyFailurealso refuses a failed last compileGetBusyFailure_WhenOnlyTheLastCompileFailed_IsNull,Run_WhenTheLastCompileFailedAtCommit_KeepsTheFixAdvice…WhenTheRequestArrives…tests, and…CompilingAtCommit…(its first state read is idle and now lands on the commit boundary)RetryAfterEditorReady…CompilingAtCommit…and both…WhenTheRequestArrives…testsRun_WhenAnUnchangedAppliedFileArrivesWhileTheEditorIsCompiling_StaysAlreadyActiveSelectedFiles…WhenTheRequestArrives…tests, and bothHotReloadDefaultFilesTestsassertsHotReloadDefaultFilesTestsasserts onlyDecidealso tookhasFailure. Removing that argument changed no test, so it was dropped. A failure kind is only ever set on a failed row, so a run with no failure always passesNone.