feat: implement issue #573 — pr-review: PRs skipped as ci-pending are never re-reviewed after CI goes green - #624
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reached
More reviews will be available in 54 minutes and 42 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, 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 include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (5)
✨ 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.
Code Review
This pull request introduces a new script scripts/sweep-stuck-reviews.sh and corresponding BATS tests to automatically re-trigger reviews for "stuck-green" pull requests that were previously skipped due to pending or failing CI. The feedback focuses on optimizing API usage by checking the dispatch limit earlier in the loop, adding a defensive check for empty head SHAs to prevent incorrect skips, and improving test helper flexibility to support empty head SHA test cases.
Dev-Lead — fix-bot-comment (applied)Changes committed and pushed. |
Review — fix requested (cycle 1/3)The automated review identified the following issues. Please address each one: Findings to fixAutomated review — NEEDS HUMAN REVIEWRisk: MEDIUM SummaryPR #624 implements the #573 stuck-review sweep (new scripts/sweep-stuck-reviews.sh + scheduled workflow + 210-line bats suite). Code quality is high and BOTH gemini-flagged bugs are already fixed at head 1db3e87 — the empty-head_sha guard exists and the MAX_DISPATCH check now runs at loop top before any gh pr view (triage evaluated the older commit e57d74a). The blocking issue is a live merge conflict (mergeable=CONFLICTING, mergeStateStatus=DIRTY): the PR cannot be merged until rebased. Escalating on the gate failure, not for security audit. Findings
Reviewed by the PR-review cascade (triage: haiku 4.5 → deep: opus 4.8 + duck: o4-mini → audit: fable 5). Reply if you need a human review. Additional tasks
The review cascade will automatically re-review after new commits are pushed. |
|
@dev-lead - please fix findings |
Dev-Lead — on-mention (no-changes)Engine ran but made no changes. |
|
Auto-rebase failed — merge conflict — this branch has conflicts with Claude will attempt to resolve this automatically. If it cannot, a follow-up comment will explain what needs manual attention. To resolve manually instead: |
1db3e87 to
4b641ec
Compare
Dev-Lead — rebase (no-changes)Agent reasoning |
Dev-Lead — fix-bot-comment (applied)Changes committed and pushed. |
|
Auto-rebase failed — merge conflict — this branch has conflicts with Claude will attempt to resolve this automatically. If it cannot, a follow-up comment will explain what needs manual attention. To resolve manually instead: |
|
Auto-rebase failed — merge conflict — this branch has conflicts with Please resolve the conflicts and push: |
Dev-Lead — review-changes (no-changes)No changes were needed for this PR. |
|
@dev-lead - resolve the rebase main conflict |
628d6c3 to
a03859f
Compare
… never re-reviewed after CI goes green
a03859f to
674fcce
Compare
Dev-Lead — review-changes (no-changes)No changes were needed for this PR. |
|
Dev-Lead — fix-bot-comment (no-changes)Agent reasoning |
…istory (#649) push_with_merge_guard did a plain `git push`, so when an engine resolved a rebase under a non-rebase intent (on-mention, review-changes) the rewritten branch could never be published — the push was rejected non-fast-forward and the run failed red, even though the rebase + conflict resolution succeeded (e.g. PR #624 stuck dirty for a day). Detect that case — a non-fast-forward rejection while HEAD has diverged from its upstream (history rewritten) — and retry once with --force-with-lease. The lease (our remote-tracking ref) makes the retry abort if the remote advanced under us, so a concurrent push is never clobbered. Normal non-fast-forwards (remote legitimately advanced, branch not diverged) still fail as before. This mirrors the dedicated rebase intent's own force-push (prompts/dev-lead/rebase.md). Closes #647 https://claude.ai/code/session_01BTcE5pAvrmNqkatFUTAetF Co-authored-by: Claude <noreply@anthropic.com>
… never re-reviewed after CI goes green (#624) * feat: implement issue #573 — pr-review: PRs skipped as ci-pending are never re-reviewed after CI goes green * fix(bot): address bot feedback [skip ci-relay] * fix(bot): address bot feedback [skip ci-relay] --------- Co-authored-by: donpetry-bot <281750570+donpetry-bot@users.noreply.github.com>
…istory (#649) push_with_merge_guard did a plain `git push`, so when an engine resolved a rebase under a non-rebase intent (on-mention, review-changes) the rewritten branch could never be published — the push was rejected non-fast-forward and the run failed red, even though the rebase + conflict resolution succeeded (e.g. PR #624 stuck dirty for a day). Detect that case — a non-fast-forward rejection while HEAD has diverged from its upstream (history rewritten) — and retry once with --force-with-lease. The lease (our remote-tracking ref) makes the retry abort if the remote advanced under us, so a concurrent push is never clobbered. Normal non-fast-forwards (remote legitimately advanced, branch not diverged) still fail as before. This mirrors the dedicated rebase intent's own force-push (prompts/dev-lead/rebase.md). Closes #647 https://claude.ai/code/session_01BTcE5pAvrmNqkatFUTAetF Co-authored-by: Claude <noreply@anthropic.com>
…istory (#649) push_with_merge_guard did a plain `git push`, so when an engine resolved a rebase under a non-rebase intent (on-mention, review-changes) the rewritten branch could never be published — the push was rejected non-fast-forward and the run failed red, even though the rebase + conflict resolution succeeded (e.g. PR #624 stuck dirty for a day). Detect that case — a non-fast-forward rejection while HEAD has diverged from its upstream (history rewritten) — and retry once with --force-with-lease. The lease (our remote-tracking ref) makes the retry abort if the remote advanced under us, so a concurrent push is never clobbered. Normal non-fast-forwards (remote legitimately advanced, branch not diverged) still fail as before. This mirrors the dedicated rebase intent's own force-push (prompts/dev-lead/rebase.md). Closes #647 https://claude.ai/code/session_01BTcE5pAvrmNqkatFUTAetF Co-authored-by: Claude <noreply@anthropic.com>
…istory (#649) push_with_merge_guard did a plain `git push`, so when an engine resolved a rebase under a non-rebase intent (on-mention, review-changes) the rewritten branch could never be published — the push was rejected non-fast-forward and the run failed red, even though the rebase + conflict resolution succeeded (e.g. PR #624 stuck dirty for a day). Detect that case — a non-fast-forward rejection while HEAD has diverged from its upstream (history rewritten) — and retry once with --force-with-lease. The lease (our remote-tracking ref) makes the retry abort if the remote advanced under us, so a concurrent push is never clobbered. Normal non-fast-forwards (remote legitimately advanced, branch not diverged) still fail as before. This mirrors the dedicated rebase intent's own force-push (prompts/dev-lead/rebase.md). Closes #647 https://claude.ai/code/session_01BTcE5pAvrmNqkatFUTAetF Co-authored-by: Claude <noreply@anthropic.com>
…istory (#649) push_with_merge_guard did a plain `git push`, so when an engine resolved a rebase under a non-rebase intent (on-mention, review-changes) the rewritten branch could never be published — the push was rejected non-fast-forward and the run failed red, even though the rebase + conflict resolution succeeded (e.g. PR #624 stuck dirty for a day). Detect that case — a non-fast-forward rejection while HEAD has diverged from its upstream (history rewritten) — and retry once with --force-with-lease. The lease (our remote-tracking ref) makes the retry abort if the remote advanced under us, so a concurrent push is never clobbered. Normal non-fast-forwards (remote legitimately advanced, branch not diverged) still fail as before. This mirrors the dedicated rebase intent's own force-push (prompts/dev-lead/rebase.md). Closes #647 https://claude.ai/code/session_01BTcE5pAvrmNqkatFUTAetF Co-authored-by: Claude <noreply@anthropic.com>



Closes #573
Implemented by dev-lead agent. Please review.