fix: compile-check keeps the records of assemblies it blocks

[hatayama]

Summary

• After an assembly had errors, the first run where it compiled again no longer rebuilds everything below it when its public surface came back the same.

User Impact

• Before: a run where an assembly had errors blocked the assemblies below it and also deleted their outputs and records. The next successful run then compiled every one of those dependents again. On a project with 561 assemblies, an assembly with 18 dependents cost about 10 extra seconds each time this happened (3 of 32 runs in one session of real use). It happened both after a full compile with errors and after a typo the changed-files check reported.
• After: the blocked assemblies keep their outputs and records. When the assembly with errors comes back with the same reference assembly, its dependents are reused, or checked on their changed files when they were edited. When it comes back with a different public surface, they compile as before.

Changes

• A blocked assembly is no longer cleaned up. It is still listed in BlockedAssemblies, and everything below it is still blocked.
• Why keeping them is safe:
  • Nothing in the blocking run reads them: every assembly that references a blocked one is blocked too.
  • A later run uses them only after its usual checks. A replayed compile needs the same input key, which reads a reference this run rebuilds by content, and outputs that still hash as recorded. A changed-files check needs the baseline's compile result on disk and the same non-source key.
• Assemblies skipped because their references kept Unity's public surface are still cleaned up, so the assemblies below them read Unity's build.
• The compile-check doc and skill no longer say a blocked assembly loses its baseline.

Verification

• Inverted pin: TestCompileUnitsBlocksTheDependentsOfAnAssemblyThatFailedToCompile now requires the blocked unit's earlier output to stay.

• Replaced test: TestBaselineRemovedByBlockedRunIsNotCalledNeverCompiled is now TestBlockedRunKeepsTheBaselineOfTheBlockedAssembly. A body edit in the blocked assembly is answered by the changed-files check once the reference comes back the same.

• New tests:

  • a blocked dependent is reused when its reference comes back with the same bytes;
  • it is compiled again when the reference comes back changed;
  • after a typo the changed-files check reported, fixing it, or undoing it, leaves the blocked dependent reused.

• Before the fix, every new or changed test failed except the "reference comes back changed" one, which describes behaviour that does not change.

• Mutations, each restored afterwards:

  Mutation	Fails
  Remove the blocked unit's outputs and records again	the inverted pin, the four reuse / baseline tests
  Remove only its records	the four reuse / baseline tests
  Remove only its outputs	the inverted pin, the four reuse / baseline tests
  Key a rebuilt reference without its content	the "reference comes back changed" test (and the existing input-key test)
  Stop blocking what is below a blocked unit	the inverted pin

• cli/dispatcher:

  • golangci-lint fmt --diff is empty; go vet ./... passes; golangci-lint run and the complexity config both report 0 issues.
  • go test ./... and go test -race ./internal/compilecheck/... pass.
  • Coverage with the CI exclusions: 94.26% (baseline 94.2).

• cli/release-automation: go test ./... passes; check-skill-size passes; the file-length check passes.

• scripts/sync-tool-docs.sh --check reports no drift.

• Repository CI does not run on pull requests into this branch; the checks above were run locally.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: hatayama/unity-cli-loop/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 07dfa323-3697-4247-b0b0-7808af6509f0

📥 Commits

Reviewing files that changed from the base of the PR and between eb7989a and 1ccbf3d.

📒 Files selected for processing: 7

• Packages/src/Editor/CliOnlyTools~/CompileCheck/Skill/SKILL.md
• cli/dispatcher/internal/compilecheck/blocked_records_test.go
• cli/dispatcher/internal/compilecheck/fast_path_test.go
• cli/dispatcher/internal/compilecheck/resultstore/baseline.go
• cli/dispatcher/internal/compilecheck/scheduler.go
• cli/dispatcher/internal/compilecheck/scheduler_test.go
• docs/compile-check.md

💤 Files with no reviewable changes: 1

• cli/dispatcher/internal/compilecheck/fast_path_test.go

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 3 remain after this review.

📝 Walkthrough

The scheduler now retains earlier outputs and records when a compile unit is blocked. Later runs can check those records and reuse the result when the reference is unchanged. Tests and documentation distinguish blocked units from skipped units.

Changes: Blocked compile-unit records

Layer / File(s)	Summary
Retain blocked outputs and records cli/dispatcher/internal/compilecheck/scheduler.go, cli/dispatcher/internal/compilecheck/scheduler_test.go, cli/dispatcher/internal/compilecheck/resultstore/baseline.go, docs/compile-check.md, Packages/src/Editor/CliOnlyTools~/CompileCheck/Skill/SKILL.md, cli/dispatcher/internal/compilecheck/fast_path_test.go	Blocked units retain earlier outputs and records. The documentation and usage guidance distinguish blocked units from skipped units. The prior test for blocked runs removing a baseline is removed.
Verify later checks and reuse cli/dispatcher/internal/compilecheck/blocked_records_test.go	Tests cover reuse when a blocked unit’s reference is unchanged, recompilation when it changes, and changed-file checks after a failure is fixed or reverted.

Priority: ⬇️ Low

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix

Merge Risk: ⚪ Minimal · up to 1ccbf

Blocked assemblies can retain prior records for later validation and reuse. No actionable merge-blocking risk is established; merge after normal checks.

Security architecture risk: 🔵 Low · up to 1ccbf

The change retains earlier compile results without weakening the inspected dependency and reuse checks. No introduced security weakness was substantiated. Remaining uncertainty concerns validation beyond the inspected recovery paths, rather than a demonstrated bypass.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• observed — The changed operation extends the lifetime of existing compile artifacts and records within the plan's output directory. The blocked-unit branch adds no command execution or permission assignment; actual compiler invocation remains in the existing compilation path.

Trust Boundaries and Controls

• inferred — No bypass from retained blocked state to an unchecked successful result was established in the inspected paths. Failed results block dependent execution before reuse is attempted, and later reuse still crosses the existing input-identity, output-integrity, and baseline-validation controls.

Resilience and Maintainability Implications

• observed — Existing recovery controls remain relevant to the longer-lived state: full compilation removes prior outputs and records before execution, interrupted execution creates no reusable result, manifests are written atomically, and the public run path serializes same-project runs with an exclusive lock.

Pre-merge checks: 5

Passed checks: 5 passed

Check name	Status	Explanation
Title check		The title clearly and concisely states the main change: compile-check now preserves records for assemblies blocked by a compilation failure.
Description check		The description directly explains the blocked-assembly record and output retention behavior, its user impact, implementation rationale, tests, and verification results.
Docstring Coverage		Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 10 functions across 4 files. (2 skipped: 2…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · 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.}