Repository navigation
fix(dev-lead): label opened PRs auto-rebase:ready to break the #711 review-ready deadlock - #1201
Conversation
…-ready deadlock The auto-rebase 'review-ready' gate (#465) only rebases PRs that are approved OR carry the auto-rebase:ready label. That label half was never wired up — no producer applies it — so the only path to eligibility is an approval. A dev-lead PR that falls behind before it is approved is therefore skipped by auto-rebase, drifts into a merge conflict, and can never be approved (pr-review skips red/conflicting PRs): a deadlock that rots the PR for weeks. dev-lead now applies auto-rebase:ready to every PR it opens, so its PRs are auto-rebase-eligible from creation and stay current until merge. The label is created idempotently (--force) first so a repo missing it does not break, and all label operations are guarded so PR creation never fails on a labeling hiccup. Addresses Part A of petry-projects/.github#711. Part C (escalate skipped-but- conflicting PRs) and standardizing the label in labels.yml are tracked follow-ups. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Juznz5V6su81ffSND8fg7s
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reached
Next review available in: 31 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: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe dev-lead issue-fix script now captures newly created pull requests and applies the ChangesDev-lead pull request labeling
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related issues
🚥 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 |
There was a problem hiding this comment.
Code Review
This pull request updates the dev-lead-fix-issue.sh script to automatically apply the auto-rebase:ready label to newly created pull requests, preventing them from falling behind and getting stuck in a deadlock. A corresponding BATS unit test has also been added. The feedback identifies two key improvements: removing an unsupported --force flag from the gh label create command to prevent it from failing, and ensuring that the temporary file in the BATS test is created within $BATS_TEST_TMPDIR for proper cleanup.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@tests/dev-lead/unit/test_fix_issue.bats`:
- Around line 742-769: Update the test setup around LABEL_RECORD and the gh
stub: create LABEL_RECORD inside STUB_BIN_DIR without exporting it, return the
JSON array "[]" for the pulls?state=open case, and retain the existing
label-recording behavior and assertions.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 39735a5f-9b9f-40f7-937e-93e672604843
📒 Files selected for processing (2)
scripts/dev-lead-fix-issue.shtests/dev-lead/unit/test_fix_issue.bats
…B_BIN_DIR The record path is baked into the gh stub via the unquoted heredoc, so exporting it was unnecessary; placing it under STUB_BIN_DIR lets teardown clean it up. (The reviewer's other suggestion — return '[]' for the pulls?state=open case — is not applicable: the mock gh bypasses --jq, so check_existing_pr reads the raw echo and needs the post-jq count '0'; returning '[]' would make [ ... -gt 0 ] throw.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Juznz5V6su81ffSND8fg7s
|
@coderabbitai I applied the first part — dropped the needless I did not change the |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
fd fix_issue.bats
fd dev-lead-fix-issue.sh
echo "---script check_existing_pr---"
rg -n "check_existing_pr" -A20 scripts/dev-lead-fix-issue.sh | head -60
echo "---test stub for pulls?state=open---"
rg -n "pulls\?state=open|state=open|LABEL_RECORD|STUB_BIN_DIR" tests/dev-lead/unit/test_fix_issue.batsLength of output: 6155 Confirmed — the mock
✏️ Learnings added
|
There was a problem hiding this comment.
Pull request overview
This PR addresses the auto-rebase “review-ready” deadlock described in #711 by ensuring dev-lead-opened PRs become auto-rebase eligible immediately upon creation via the auto-rebase:ready label.
Changes:
- Capture the created PR URL in
dev-lead-fix-issue.sh, echo it (preserving prior output), and applyauto-rebase:readyafter PR creation. - Add a dev-lead unit regression test asserting that an opened PR is labeled
auto-rebase:ready.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| scripts/dev-lead-fix-issue.sh | Captures gh pr create output and applies the auto-rebase:ready label after opening a PR. |
| tests/dev-lead/unit/test_fix_issue.bats | Adds a regression test validating that opened PRs are labeled auto-rebase:ready. |
Dev-Lead — review-changes (applied)Changes committed and pushed. |
Dev-Lead — review-changes (applied)Changes committed and pushed. |
|
Dev-Lead — waiting on PR blockers (intent: review-changes)PR: #1201 |
|
Note @don-petry I reviewed this PR and no code changes were needed, but it still has blocking checks or reviews (failing or cancelled checks, or changes-requested reviews), so I cannot mark it done yet. I'll re-check automatically. |
donpetry-bot
left a comment
There was a problem hiding this comment.
Automated review — APPROVED ✓
Risk: MEDIUM
Reviewed commit: 9c5d48d792030f851677fca3ffc7f969f66c5efd
Review mode: triage-approved (single reviewer)
Summary
Wires up the previously-dead 'auto-rebase:ready' label half of the auto-rebase review-ready eligibility gate: dev-lead-fix-issue.sh now captures the created PR URL, idempotently ensures the label exists, and applies it to every PR it opens — making dev-lead PRs auto-rebase-eligible from creation and breaking the unapproved→conflicting→never-approved deadlock described in petry-projects/.github#711. All label operations are guarded (output suppressed, || true) so PR creation can never fail on a labeling hiccup, and the prior stdout behavior (PR URL echoed) is preserved. A new bats regression test stubs gh to assert the opened PR receives the label. Change is small (2 files, +69/−2), well-scoped, and matches the triage tier's low-risk assessment.
Linked issue analysis
No closing issue in this repo; the PR addresses cross-repo issue petry-projects/.github#711 (Part A) and the #465 eligibility gate. The stated root cause (label never applied anywhere in the org) and the fix mechanism are consistent with the diff, and the PR body documents a manual validation run (bmad-bgreat-suite#205 flipped from skipped to rebased) confirming the mechanism.
Findings
- No blocking findings.
- Earlier reviewer concerns (gh label create --force overwriting label metadata; test temp-file hygiene; misleading test comment) were all addressed in follow-up commits — the final code uses 'gh label create ... || true' without --force, and the test keeps its record file in STUB_BIN_DIR (cleaned by teardown). All 5 review threads are resolved; CodeRabbit's changes-requested review was superseded by its APPROVED review.
- Secret scanning MCP tool not available in this run; the gitleaks CI check passed on the head SHA.
CI status
All checks green on 9c5d48d (shellcheck, bats, unit-tests, CodeQL, SonarCloud quality gate, gitleaks, agent-shield, all structure/permission guards). A few CANCELLED entries are superseded duplicate runs of the same jobs that later succeeded; SKIPPED entries are conditional dependency-audit jobs for absent ecosystems.
Reviewed automatically by the PR-review agent (single-reviewer mode: fable 5). Reply if you need a human review.
donpetry-bot
left a comment
There was a problem hiding this comment.
Automated review — APPROVED ✓
Risk: MEDIUM
Reviewed commit: 9c5d48d792030f851677fca3ffc7f969f66c5efd
Review mode: triage-approved (single reviewer)
Summary
Adds an auto-rebase:ready labeling step to dev-lead-fix-issue.sh so every dev-lead-opened PR is auto-rebase-eligible from creation, breaking the review-ready deadlock diagnosed in petry-projects/.github#711 (Part A). The PR-create output is captured, the label is created idempotently if missing, and all label operations are guarded with || true so PR creation can never fail on a labeling hiccup. A new bats regression test asserts the opened PR receives the label. Change is small (2 files, +69/-2), well-tested, and validated live against a stuck PR (bmad-bgreat-suite#205 flipped from skipped to rebased).
Linked issue analysis
No closing issue reference in this repo. The PR implements Part A of petry-projects/.github#711 (open), which documents that the auto-rebase 'review-ready' gate's label path was never wired up (0/55 open org PRs carry the label), deadlocking unapproved PRs that drift into conflicts. The change directly and substantively addresses that root cause for dev-lead PRs; Parts B/C are explicitly tracked as follow-ups on #711.
Findings
- No security concerns: no auth/secrets/credentials touched; new gh calls (label create, pr edit) use existing authenticated CLI with errors suppressed and guarded (|| true), so failure modes are benign.
- Prior bot findings (gemini, CodeRabbit, Copilot) were all addressed and every review thread is resolved: the invalid/overwriting 'gh label create --force' was replaced with a guarded plain create, the test record file was moved under STUB_BIN_DIR (cleaned by teardown), and the misleading test comment was fixed. CodeRabbit's final review is APPROVED. Note: the PR description still mentions '--force' but the code correctly does not use it — cosmetic staleness only, not blocking.
- Test stub correctly escapes $* in the unquoted heredoc and asserts 'add-label auto-rebase:ready' is recorded; suite reported 21/21 green.
- Secret scanning MCP tool unavailable in this environment; gitleaks CI check passed (SUCCESS).
CI status
All checks green at 9c5d48d: shellcheck, bats, unit-tests, CodeQL (actions+python), SonarCloud quality gate, gitleaks secret scan, agent-shield, holdout-guard, and all stub/permission validators SUCCESS. A few CANCELLED entries (dev-lead/dispatch, review/review, ci-relay) are superseded duplicate runs with later SUCCESS conclusions for the same checks. mergeStateStatus BLOCKED reflects only the pending required review.
Reviewed automatically by the PR-review agent (single-reviewer mode: fable 5). Reply if you need a human review.



Problem
Auto-rebase's
review-readyeligibility gate (#465) only rebases PRs that are approved OR carry theauto-rebase:readylabel. The label half was never wired up — nothing applies it (0/55 open org PRs carry it, it's in nolabels.yml). So the only path to eligibility is an approval, which creates a deadlock for every dev-lead PR that falls behind before approval:This is the root cause of the fleet's stuck
CONFLICTING + REVIEW_REQUIREDPR cohort. Full diagnosis + evidence in petry-projects/.github#711.Fix (Part A of #711)
dev-lead-fix-issue.shnow appliesauto-rebase:readyto every PR it opens, so dev-lead PRs are auto-rebase-eligible from creation and stay current until merge — before divergence becomes intractable.gh label create --force, idempotent) so a repo missing it doesn't break, then adds it.|| true, output suppressed) — a labeling hiccup can never fail PR creation.Tests
auto-rebase:ready.test_fix_issue.batssuite green (21/21);bash -n+ shellcheck clean.Validation
Manually applying
auto-rebase:readyto the stuck bmad-bgreat-suite#205 flipped it fromnot eligible ... — skippingtoupdating branchon the next auto-rebase run (run 29298232627) — confirming the mechanism.Follow-ups (tracked on #711, not in this PR)
needs-manual-rebase) so nothing rots silently — also covers the ~2500-comment-cap failure mode found on docs(pr-review-agent): document read:org requirement for team review requests #205.auto-rebase:readyin the orglabels.yml+ fleet sync.🤖 Generated with Claude Code
https://claude.ai/code/session_01Juznz5V6su81ffSND8fg7s
Summary by CodeRabbit
New Features
auto-rebase:readylabel.Tests