fix(cef): raise STARTUP_GRACE_MS to 15s (real post-merge CI failure) - #401
Conversation
…ilure main's own post-merge CEF Learning Harness run (triggered by PR #400's merge) failed with the exact "Cycle 1: no FFI boundary proof" symptom this file's own comment already documents as a known runner-speed- variance pattern (STARTUP_GRACE_MS was raised 4000->10000ms for the same reason before). Real, measured evidence for a plausible contributing factor this time: PR #400's -g flag on worldscript_host (apps/desktop-cef/CMakeLists.txt) grew the binary from 1.34MB to 6.33MB (4.7x). Cycles 2/3 in the same run always passed at the old 10s window — this only ever hits the cold first launch, consistent with slower first-time I/O on a larger binary under a loaded runner, not a logic regression.
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
🤖 CodeAnt AI — Review Status
|
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. |
The latest updates on your projects. Learn more about Vercel for GitHub.
|
ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing |
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in:52 minutes Limit details: You’ve used the included review currently available. Your 60 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. 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 within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
Comment |
Reviewer's guide (collapsed on small PRs)Reviewer's GuideIncrease the CEF startup grace timeout to reduce flaky CI failures on the first launch cycle, and document the rationale tied to recent binary size growth. Sequence diagram for updated CEF startup grace timeout behaviorsequenceDiagram
participant CI_runner
participant run_launch_cycle_proof
participant cef_browser
CI_runner->>run_launch_cycle_proof: start_cycle
run_launch_cycle_proof->>cef_browser: launch_browser_process
run_launch_cycle_proof->>run_launch_cycle_proof: Promise.race(OnAfterCreated, STARTUP_GRACE_MS=15000)
alt OnAfterCreated before timeout
cef_browser-->>run_launch_cycle_proof: OnAfterCreated
run_launch_cycle_proof-->>CI_runner: record FFI_boundary_proof
else timeout before OnAfterCreated
run_launch_cycle_proof-->>CI_runner: report_cycle_no_FFI_boundary_proof
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
🏁 CodeAnt Quality Gate ResultsCommit: ✅ Overall Status: PASSEDQuality Gate Details
|
There was a problem hiding this comment.
This PR correctly addresses the post-merge CI failure by increasing STARTUP_GRACE_MS from 10s to 15s. The timeout adjustment is well-justified with measured evidence (4.7x binary size increase from PR #400's debug symbols) and properly documented. The change is minimal, focused, and introduces no defects.
The implementation is sound: the Promise.race pattern ensures successful launches resolve immediately without waiting the full timeout, so this only affects the genuine-hang failure path as intended. No blocking issues found.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
Uh oh!
There was an error while loading. Please reload this page.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
CodeAnt finding on PR #401, verified real: the comment claimed the grace-period bump "only ever hits the cold first launch" (runCycle), but STARTUP_GRACE_MS is a shared constant also used by runCrashReportingProofCycle's own renderer-crash-detection timeout (line ~278). The bump widens that proof's failure-detection window too — harmless (strictly more lenient, same CI-runner-speed rationale applies to both), but the comment understated the actual scope. Updated to describe both consumers rather than splitting into a dedicated timeout, since there's no evidence the two need to differ.
Uh oh!
There was an error while loading. Please reload this page.
User description
Summary
main's own post-merge CEF Learning Harness run (triggered by PR #400's merge) failed with the exact "Cycle 1: no FFI boundary proof" symptom this file's own comment already documents as a known runner-speed-variance pattern (STARTUP_GRACE_MSwas raised4000->10000msfor the same reason before, on unrelated code).Real, measured evidence for a plausible contributing factor this time: PR #400's
-gflag onworldscript_host(apps/desktop-cef/CMakeLists.txt) grew the binary from 1.34MB to 6.33MB (4.7x), comparing the last pre-#400 successful run'sls -laoutput to this failing run's. Cycles 2/3 in the same run always passed at the old 10s window — this only ever hits the cold first launch, consistent with slower first-time I/O on a larger binary under a loaded runner, not a logic regression.Bumped
STARTUP_GRACE_MS10000 -> 15000ms. Cost is asymmetric: a successful launch resolves thePromise.raceimmediately and never waits the full window, so this only adds latency to the genuine-hang failure path, not the happy path.Test plan
gh run rerun --failed) as an independent data point while this fix was being preparedmainpushes for recurrence🤖 Generated with Claude Code
Summary by Sourcery
Increase the CEF startup grace period to 15 seconds to prevent cold-start timing variance from causing false CI failures.
Bug Fixes:
Enhancements:
CodeAnt-AI Description
Prevent false CEF launch failures on slow cold starts
What Changed
Impact
✅ Fewer false CI launch failures✅ More reliable cold-start validation✅ No added delay for successful launches💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.