The rate-limit message is noise; the review count is signal - #17
Conversation
…tions Fifth occurrence, and #16 supplied the case that settles the wording: the same "Review rate limited" message appeared on an unreviewed head (count 0) and on a reviewed one (count 1) within a single PR. So the message is not a tell to watch for; it carries no information either way, and the row now says so without hedging — one integer per head, 0 means do not merge. Also records that verification is per head rather than per PR: every push moves the target and expires the previous answer. #16 needed three, and its last head never got a review, which is why this refinement is landing as its own PR rather than riding along in that one. Docs-only (docs/**.md), so Gate B is N/A per CLAUDE.md §5's prose exemption.
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
|
Warning Review limit reached
Next review available in: 49 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: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
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 |
Greptile SummaryUpdates the CodeRabbit review-bot guidance to clarify that review-record count is the reliable completion signal and that verification must be repeated for every new PR head.
Confidence Score: 5/5The documentation-only PR appears safe to merge. The revised wording accurately distinguishes status-check completion from a CodeRabbit review record and aligns the merge guidance with the existing commit-specific verification command. Important Files Changed
Reviews (1): Last reviewed commit: "docs(bots): the message is noise, the co..." | Re-trigger Greptile |
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
Merging as an explicit human exception — head `c62455b` was never reviewed by CodeRabbit. Per-head verification (docs/pr-review-bots.md), run twice against the live head `c62455bc66bf66407cd7c7b8b3508ed4d70e4035`:
CodeRabbit's status check is green in both cases. The count is the arbiter, and it says unreviewed. What its comments say — a variant worth recording, distinct from the four "Review rate limited" occurrences already documented:
Decision: Daniel's, explicitly, following the #14 precedent (green check, re-trigger produced nothing, merged on a recorded human decision). This PR is docs-only — it changes |
|
Your plan includes PR reviews subject to rate limits. More reviews will be available in 43 minutes. |
Docs-only, two files, no plugin path — no version bump. CodeRabbit leaves Wait for after five consecutive unreviewed heads (#12, #13, #15, #16, #17 — the last with zero review records on the PR) followed by a genuine review on #18. Real findings source, unpredictable delivery, and a completion signal that fires regardless of whether a review happened: the opportunistic category by this file's own definition. Wait for is now empty. Row additions: the status check goes green whether or not a review happened, and `@coderabbitai review` is a no-op while automatic reviews are active (CodeRabbit's own message on #17), which retroactively explains #14's "re-trigger produced nothing". Plan corrected to Free; "Pro Plus" was observed on PR #1 only. The count rule's two facts separated: the per-head count remains the arbiter of whether a head was reviewed, for any bot; the recorded-human-decision requirement binds only bots under Wait for, and is dormant while that list is empty. Every head reaching a PR has already passed Gate B, so a quiet supplementary reviewer needs no exception. MANIFEST.md: the bare `CLAUDE.md` row resolved to the repo root and produced a false Major on #18. Qualified to source-files/CLAUDE.md, with the three files distinguished, and root §6 (context canary) recorded as deliberately outside the §1–§5 template range and never to be synced into the scaffolded template. Pre-merge diagnostic: per-head count 1 on head 2634bf2 — reviewed. One Minor finding (drop or explicitly optionalize the re-trigger step) collected, not actioned, per §5's Minor/Nit rule. Gate B: N/A — every path is explanatory documentation per §5's prose rule. Battery green at each commit.
Resolves the Minor collected on #19. The file established that `@coderabbitai review` is a no-op while automatic reviews are active, then instructed operators to run it anyway inside the deterministic merge verification — described twice, once imperatively and once undercut. The imperative is out; the procedure ends at the DISMISSED filter and the step survives once, as an explicitly optional note beside the human-exception clause it precedes, which also scopes it to Wait-for bots. Facts kept: the no-op behaviour with its #17 source, that #14 and #17 both produced nothing, that nothing claims a re-trigger cannot work (only that this account has never seen one work), and that `full review` must not be claimed effective without a run observed here. Pre-merge diagnostic: per-head count 0 on head 55c3d74 — which blocks nothing, Wait for being empty. Recorded on the PR: this 0 is a false negative. CodeRabbit reported "No actionable comments were generated in the recent review" over 286c55f..55c3d74, so the head was reviewed and simply had nothing to say; a zero-finding review posts no review record. The count conflates "not reviewed" with "reviewed, clean". Follow-up, not fixed here. Gate B: N/A — single explanatory documentation path per §5's prose rule. Battery green before commit.
1 participant
Docs-only follow-up to #16, split out because its head never got a genuine review and the rule this row states does not make exceptions for the row itself.
What changes
docs/pr-review-bots.md— the CodeRabbit completion-signal note reaches its terminal form:Plus: verification is per head, not per PR.
Why this wording, and not the previous one
The row already said "never merge on the check alone". That was right but incomplete, because it implied "Review rate limited" was the thing to watch for. #16 disproved that inside a single PR:
c6c1850085c5ce51The same message on both. So it carries no information either way — there is nothing to interpret, weigh, or watch for. One integer per head:
0means do not merge, anything else means the head was reviewed. The green tick establishes that CodeRabbit's check finished, which is a different fact about a different thing.The per-head clause records the other thing #16 demonstrated: every push moves the head and expires the previous answer. That PR needed three verifications, and its final head went unreviewed past the point of waiting — which is why this commit is here instead of there.
Five occurrences now: #12, #13, #15, and #16 twice.
Gate B
N/A — the staged path is
docs/pr-review-bots.md, explanatory documentation underdocs/**.md, which CLAUDE.md §5 exempts. A wrong sentence here costs a confused reader rather than broken behaviour.Merging
No urgency, and no exception: this merges when its own head has a genuine review record. The rule applies to the PR that writes the rule.