chore: immediately post a commit check when a dry run starts#1041
chore: immediately post a commit check when a dry run starts#1041adityachoudhari26 merged 1 commit intomainfrom
Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 9 minutes and 43 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ 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 |
There was a problem hiding this comment.
Pull request overview
Adds an early GitHub check-run update so deployment plan target “dry run” results show a processing / in_progress status on the PR as soon as planning starts (fixes #1035).
Changes:
- Trigger
MaybeUpdateTargetCheck(...)at the start ofdeploymentplanresult.Controller.Processwhen the target result has no persisted agent state yet. - Continue to update the check run on terminal outcomes (unsupported/errored/completed) as before.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if len(result.AgentState) == 0 { | ||
| if checkErr := MaybeUpdateTargetCheck(ctx, c.getter, resultID); checkErr != nil { | ||
| span.RecordError(checkErr) | ||
| } | ||
| } |
There was a problem hiding this comment.
This initial MaybeUpdateTargetCheck call can run concurrently for multiple results belonging to the same target (worker maxConcurrency > 1 and targets can have multiple agent results). Since MaybeUpdateTargetCheck upserts via “list-by-name then create”, concurrent starts can race and create duplicate check runs / extra GitHub API traffic, and later updates may hit a non-deterministic check run ID when multiple exist. Consider adding an idempotency mechanism (e.g., persist the check_run_id per target+sha, or add a per-target lock/serialized updater, or retry create by re-listing on create failure) to ensure only one check run is created per target.
| if len(result.AgentState) == 0 { | ||
| if checkErr := MaybeUpdateTargetCheck(ctx, c.getter, resultID); checkErr != nil { | ||
| span.RecordError(checkErr) | ||
| } | ||
| } |
There was a problem hiding this comment.
New behavior (posting the initial in-progress GitHub check when AgentState is empty) isn’t covered by the existing unit tests in this package. Consider adding a test that asserts the “check update” path is exercised on the first Process call (e.g., have the mock Getter count calls to GetTargetContextByResultID / ListDeploymentPlanTargetResultsByTargetID and assert they’re invoked when AgentState is nil/empty).
fixes #1035