policy(contributor): grandfather pre-cutoff tier declarations; reap dissolved merge groups#6581
Conversation
…issolved merge groups The Frontier-only tier rule landed in #6579 with no cutoff clause, so read literally it closes PRs opened weeks earlier that declared Sonnet or Composer accurately under the then-current Standard tier. That inverts the incentive the disclosure rule exists to create: the only PRs the rule can find are the ones whose authors filled the field in honestly. Scope it to PRs opened on or after 2026-07-24 and cross-reference the cutoff from the Tier-line section. Add a janitor for dissolved merge groups. Every queue reformation deletes the gh-readonly-queue refs and mints new ones, and ci.yml's concurrency group is keyed on github.ref -- unique per synthesized ref -- so cancel-in-progress can never match the superseded runs. One evening accumulated 22 such runs (~198 queued jobs) against a 20-job concurrency cap. This cannot be fixed in the concurrency key: GitHub's expression language has no regex or split, so a concurrency.group cannot extract the PR number from the ref, and keying on the base branch would cancel live speculative groups -- which the queue reads as a failed check and evicts the entry for. Cancelling runs whose ref no longer resolves is the safe equivalent, and only queued/in_progress runs are considered so a completed run whose ref was reaped is never touched. Paired with a ruleset change (applied out-of-band): max_entries_to_build 5 -> 2, since 5 speculative groups x 9 jobs requests 45 jobs against a 20-job cap; and check_response_timeout_minutes 60 -> 120, which evicted an approved PR ten seconds past deadline during a hosted-runner stall whose CI then passed.
|
Warning Review limit reached
Next review available in: 41 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: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
1 participant
The Frontier-only tier rule landed in #6579 with no cutoff clause, so read
literally it closes PRs opened weeks earlier that declared Sonnet or Composer
accurately under the then-current Standard tier. That inverts the incentive the
disclosure rule exists to create: the only PRs the rule can find are the ones
whose authors filled the field in honestly. Scope it to PRs opened on or after
2026-07-24 and cross-reference the cutoff from the Tier-line section.
Add a janitor for dissolved merge groups. Every queue reformation deletes the
gh-readonly-queue refs and mints new ones, and ci.yml's concurrency group is
keyed on github.ref -- unique per synthesized ref -- so cancel-in-progress can
never match the superseded runs. One evening accumulated 22 such runs (~198
queued jobs) against a 20-job concurrency cap.
This cannot be fixed in the concurrency key: GitHub's expression language has no
regex or split, so a concurrency.group cannot extract the PR number from the ref,
and keying on the base branch would cancel live speculative groups -- which the
queue reads as a failed check and evicts the entry for. Cancelling runs whose ref
no longer resolves is the safe equivalent, and only queued/in_progress runs are
considered so a completed run whose ref was reaped is never touched.
Paired with a ruleset change (applied out-of-band): max_entries_to_build 5 -> 2,
since 5 speculative groups x 9 jobs requests 45 jobs against a 20-job cap; and
check_response_timeout_minutes 60 -> 120, which evicted an approved PR ten
seconds past deadline during a hosted-runner stall whose CI then passed.