feat: add --compile-wait-timeout-seconds to uloop compile - #2033
Conversation
Large projects can exceed the hard-coded 10-minute CLI wait. Expose the timeout in the compile tool schema and skill docs so callers can set it. Co-authored-by: Cursor <cursoragent@cursor.com>
Read CompileWaitTimeoutSeconds from tool params and use it as the status-poll deadline so large compiles can wait longer than 10 minutes. Co-authored-by: Cursor <cursoragent@cursor.com>
|
Warning Review limit reached
Next review available in: 39 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe compile CLI gains a configurable wait timeout with schema and documentation updates. The project runner validates the parameter, applies it to compile waiting, warns beyond Unity’s retention window, and reports the configured duration in timeout errors. ChangesConfigurable compile timeout
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant CompileCommand
participant TimeoutParser
participant UnityCompileWait
participant TimeoutError
CompileCommand->>TimeoutParser: Read CompileWaitTimeoutSeconds
TimeoutParser-->>CompileCommand: Return validated wait duration
CompileCommand->>UnityCompileWait: Wait for compilation using duration
UnityCompileWait-->>CompileCommand: Completion or timeout
CompileCommand->>TimeoutError: Format configured timeout
Possibly related issues
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
cli/project-runner/internal/projectrunner/execution_errors.go (1)
23-30: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winRemove the fixed recovery-window promise.
The configured timeout now varies, but Line 28 still promises about 10 more minutes of result recovery. This contradicts the retention warning for values above 1200 seconds. Tell callers to retry promptly and state that recoverability depends on the configured wait, or calculate it dynamically.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@cli/project-runner/internal/projectrunner/execution_errors.go` around lines 23 - 30, Update the timeout recovery guidance in the NextActions list of execution errors so it no longer promises a fixed 10-minute retrieval window. In the retry instruction, tell callers to retry promptly and describe result recoverability as dependent on the configured wait/retention settings; keep the compile retry and fallback restart guidance unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@cli/project-runner/internal/projectrunner/compile_wait.go`:
- Around line 77-91: Update compileWaitTimeoutFromParams to parse the timeout as
int64 and reject values exceeding the maximum representable time.Duration in
seconds before multiplying by time.Second. Preserve the existing invalid-value
error behavior, and add a boundary test covering the maximum accepted value and
the first overflowing value.
In `@Packages/src/Editor/FirstPartyTools/Compile/Skill/SKILL.md`:
- Line 24: Add [--compile-wait-timeout-seconds <seconds>] to the uloop compile
usage synopsis in Packages/src/Editor/FirstPartyTools/Compile/Skill/SKILL.md,
then regenerate the copies in .agents/skills/uloop-compile/SKILL.md and
.claude/skills/uloop-compile/SKILL.md through the normal workflow; do not edit
the generated skill files directly.
---
Outside diff comments:
In `@cli/project-runner/internal/projectrunner/execution_errors.go`:
- Around line 23-30: Update the timeout recovery guidance in the NextActions
list of execution errors so it no longer promises a fixed 10-minute retrieval
window. In the retry instruction, tell callers to retry promptly and describe
result recoverability as dependent on the configured wait/retention settings;
keep the compile retry and fallback restart guidance unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 8c4a72d2-d72c-4061-8fea-443d150d948f
📒 Files selected for processing (11)
.agents/skills/uloop-compile/SKILL.md.claude/skills/uloop-compile/SKILL.mdPackages/src/Editor/FirstPartyTools/Compile/CompileSchema.csPackages/src/Editor/FirstPartyTools/Compile/Skill/SKILL.mdcli/common/tools/default-tools.jsoncli/dispatcher/shared-inputs-stamp.jsoncli/project-runner/internal/projectrunner/compile_wait.gocli/project-runner/internal/projectrunner/compile_wait_test.gocli/project-runner/internal/projectrunner/execution_errors.gocli/project-runner/internal/projectrunner/run.gocli/project-runner/shared-inputs-stamp.json
Values above MaxInt64/time.Second wrap to a negative duration and look like an immediate timeout. Also add the new flag to the compile usage line. Co-authored-by: Cursor <cursoragent@cursor.com>
|
Re: the outside-diff comment on |
cli_compile_request_prepared always recorded the default 600000ms even when --compile-wait-timeout-seconds was set. Pass the resolved duration through, and add runCompileWithDomainReloadWaitWithDeps tests that fail if that wiring regresses to the package constant. Co-authored-by: Cursor <cursoragent@cursor.com>
1 participant
Summary
uloop compilenow accepts--compile-wait-timeout-seconds(default 600) so large projects can wait longer than the previous hard-coded 10 minutes beforeCOMPILE_WAIT_TIMEOUT.User Impact
Changes
CompileWaitTimeoutSecondsto the compile tool schema, skill docs, and generated catalog/skill copies.COMPILE_WAIT_TIMEOUTmessaging.cli/commoncatalog change.Verification
scripts/check-go-cli.shpassed.scripts/sync-tool-docs.sh --checkpassed.dist/darwin-arm64/uloop compile --compile-wait-timeout-seconds 1 --force-recompilereturnedCOMPILE_WAIT_TIMEOUTwithtimed out after 1000ms.dist/darwin-arm64/uloop compilesucceeded afterward.