Uh oh!
There was an error while loading. Please reload this page.
ci: don't block PRs when CodeRabbit is rate limited - #4175
Conversation
CodeRabbit posts a failing "CodeRabbit" commit status ("Review rate
limited") when it can't review a PR, which turns the checks rollup red
even when thepastaclaw has already reviewed.
- Add .coderabbit.yaml with reviews.fail_commit_status: false so a
rate-limited review no longer fails the commit status (overrides the
org/UI setting).
- Add an "AI Review" workflow check that passes once either CodeRabbit
or thepastaclaw has submitted a review, and re-runs when a review is
submitted. Either reviewer satisfies it, so a rate-limited CodeRabbit
doesn't block a PR that thepastaclaw reviewed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>Warning Ignoring CodeRabbit configuration file changes. For security, only the configuration from the base branch is applied for open source repositories. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughChangesAI review enforcement
Estimated code review effort: 2 (Simple) | ~15 minutes Sequence Diagram(s)sequenceDiagram
participant PullRequest
participant AIReviewWorkflow
participant GitHubReviews
PullRequest->>AIReviewWorkflow: Trigger on PR activity or review submission
AIReviewWorkflow->>GitHubReviews: Paginate pull request reviews
GitHubReviews-->>AIReviewWorkflow: Return non-pending reviews
AIReviewWorkflow-->>PullRequest: Pass or fail the AI Review check
🚥 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 |
thepastaclaw
commented
Jul 21, 2026
🕓 Ready for review — 19 ahead in queue (commit f2b13e8) |
Uh oh!
There was an error while loading. Please reload this page.
Issue being fixed or feature implemented
When CodeRabbit is rate limited it posts a failing
CodeRabbitcommit status ("Review rate limited"), which turns the PR checks rollup red (e.g. #4171) even when thepastaclaw has already reviewed the PR. The desired policy is: either a CodeRabbit or a thepastaclaw review must happen — a rate-limited CodeRabbit should not block a PR on its own.What was done?
.coderabbit.yamlwithreviews.fail_commit_status: falseso CodeRabbit no longer fails its commit status when a review can't be performed (this checked-in config overrides the org/UI setting where the failing status is currently enabled)..github/workflows/pr-ai-review.yml) that passes once eithercoderabbitaiorthepastaclawhas submitted a review on the PR. It re-runs automatically onpull_request_reviewevents, so it flips green as soon as the first review lands. Because either reviewer satisfies it, a rate-limited CodeRabbit never blocks a PR that thepastaclaw reviewed (and vice versa).Note: the
CodeRabbitstatus was never a required check in branch protection — the failing status was cosmetic but made PRs look blocked. If we want the new gate to be enforced, the contextAI Review / CodeRabbit or PastaClaw reviewcan be added to the required status checks on the dev branches after this merges.How Has This Been Tested?
reviews.fail_commit_statusexists (defaultfalse) in the CodeRabbit v2 config schema.CodeRabbitstatus on feat(platform)!: document history system contract with per-doctype opt-in #4171 is not a required check, and that this workflow's review query matches the reviews present there (thepastaclaw has reviewed → gate would pass).Breaking Changes
None.
Checklist:
For repository code-owners and collaborators only
🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Chores