Repository navigation
fix(readme-refresh): retry rolling-branch push through the auto-merge race - #1261
Conversation
… race The single rolling `chore/readme-refresh` branch is reused every run, and the prior refresh PR often auto-merges mid-run — deleting or fast-forwarding the branch and staling the --force-with-lease lease, so the next push fails and (correctly) reds the run. That's a benign race, not a real error. Retry the push up to 3×, running `git fetch --prune` between attempts so the lease re-evaluates against current remote state (branch deleted → recreate; branch moved → overwrite). Only a persistent failure (e.g. lost write access) fails the run, preserving the loud-failure behavior for genuine problems. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
|
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 (1)
✨ 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 |
Dev-Lead — review-changes (no-changes)No changes were needed for this PR. |
|
Dev-Lead — fix-bot-comment (no-changes)Agent reasoning |
|
Advisory bots were rate-limited; auto-approval is withheld until they recover. pr-review-sweep will re-review this PR after 2026-07-15T05:03:22Z. |
There was a problem hiding this comment.
Pull request overview
This PR hardens the readme-refresh automation against a benign race where the rolling chore/readme-refresh branch can be deleted or fast-forwarded mid-run (due to auto-merge of the prior refresh PR), causing git push --force-with-lease to fail.
Changes:
- Add a bounded retry loop (3 attempts) around the rolling-branch
git push --force-with-lease. - Between retries, run
git fetch --pruneto re-sync the remote-tracking ref so the lease can re-evaluate against current remote state.
| local push_ok=0 attempt | ||
| for attempt in 1 2 3; do | ||
| if git -C "$dir" push --force-with-lease --quiet origin "$BRANCH" 2>/dev/null; then | ||
| push_ok=1; break | ||
| fi | ||
| warn "$full_repo: push to $BRANCH failed (attempt $attempt/3) — re-syncing remote ref and retrying" | ||
| git -C "$dir" fetch --prune --quiet origin 2>/dev/null || true | ||
| sleep 3 | ||
| done | ||
| if [ "$push_ok" -ne 1 ]; then | ||
| echo "::error::readme-refresh: $full_repo: git push to $BRANCH failed after 3 attempts — READMEs NOT updated (check GH_TOKEN write access / branch state)" >&2 | ||
| return 1 | ||
| fi |
| local push_ok=0 attempt | ||
| for attempt in 1 2 3; do | ||
| if git -C "$dir" push --force-with-lease --quiet origin "$BRANCH" 2>/dev/null; then | ||
| push_ok=1; break | ||
| fi |
Problem
The single rolling
chore/readme-refreshbranch is reused every run. When the previous refresh PR auto-merges mid-run, GitHub deletes/fast-forwards that branch, staling the--force-with-leaselease → the next push fails and (correctly, per the loud-failure hardening) reds the run. Observed live: run 29386746375 failed because PR #1246 merged at 03:43 as the run pushed at 03:42.That's a benign race, not a real error — the immediate re-run on the clean branch succeeded.
Fix
Retry the push up to 3×, running
git fetch --prunebetween attempts so--force-with-leasere-evaluates against current remote state:Only a persistent failure (e.g. genuinely lost write access) fails the run — so real problems still go red loudly.
Validation:
bash -n+ shellcheck clean. Behavioral fix; end-to-end coverage is the weekly job surviving the next auto-merge overlap.🤖 Generated with Claude Code