fix(dx): batch bot — push rollup objects instead of refs-API update, fix add-then-list race (dev) - #13535
fix(dx): batch bot — push rollup objects instead of refs-API update, fix add-then-list race (dev)#13535ntindle wants to merge 2 commits into
Conversation
…-then-list race Forward-port of the master hotfix (#13534) so the copies stay in sync; preserves dev's exact-match ref-check hardening context by replacing the whole refs-API block with the force-push. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jm3mCG9okfdGtAXtFaDF9A
WalkthroughThe batch bot now ensures the just-batched PR is included even when the member index lags, and publishes the assembled rollup branch through a direct forced Git push. ChangesBatch rollup flow
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
🔍 PR Overlap DetectionThis check compares your PR against all other open PRs targeting the same branch to detect potential merge conflicts early. 🟡 Medium Risk — Some Line OverlapThese PRs have some overlapping changes:
Summary: 0 conflict(s), 1 medium risk, 0 low risk (out of 1 PRs with file overlap) Auto-generated on push. Ignores: |
…fix add-then-list race (#13536) Replaces #13534 (auto-repointed to dev by the base-branch enforcer — the branch needed a `hotfix/*` name to target master). Same commit. Dev forward-port: #13535. ### Why / What / How **Why:** The batch bot's first live runs failed at the final step both times it got there: 1. `buildRollup` merges member branches into a **local** commit in the runner, then points the remote `batch/rollup` ref at that SHA via the git refs API — which 422s ("Object does not exist") because the server never received the merge objects. Hard blocker; the whole /batch flow dies here (live evidence: run 29135797524). 2. The first `/batch` on a PR reports "Current batch (0): none" — `cmdBatch` adds the label then immediately lists members, but GitHub's label index lags `pr edit --add-label` (live evidence: run 29135796249). **What/How:** - Replace the refs-API PATCH/POST dance with a single `git push --force origin HEAD:refs/heads/batch/rollup` — uploads objects and creates/force-moves the branch in one step under the bot's checkout token (array-arg `execFileSync`, no shell). - `rebuildAndReport` takes an optional `ensureNumber`: the just-labeled PR is fetched directly and unioned into the member list so the first /batch builds immediately. Targets `master` because issue_comment/repository_dispatch workflows execute the default branch's copy of the bot — a dev-only fix wouldn't take effect until the next release merge. ### Changes 🏗️ - `.github/batch-bot/batch.mjs`: force-push rollup branch; union just-added PR into the rebuild ### Checklist 📋 #### For code changes: - [x] I have clearly listed my changes in the PR description - [x] I have made a test plan - [x] I have tested my changes according to the test plan: - [x] `node --check` clean; both failure modes reproduced from live run logs - [ ] Real e2e: re-trigger `/batch` after merge (batch labels already on #13533/#13526/#13530/#13532) 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01Jm3mCG9okfdGtAXtFaDF9A <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes how the bot-owned rollup branch is updated (force-push) and batch membership is assembled; limited to CI/batch-bot infrastructure but affects preview deploy and batch-merge flows. > > **Overview** > Fixes two production failures in the batch bot’s rollup publish and member listing. > > **Rollup publish:** After local merges, the bot no longer updates `batch/rollup` via the Git refs API (which 422’d because the server never had the merge objects). It now **`git push --force`** to `HEAD:refs/heads/batch/rollup`, uploading objects and moving the branch in one step under the checkout token. > > **First `/batch` race:** `rebuildAndReport` accepts an optional **`ensureNumber`**. When `/batch` adds a label, the just-labeled PR is fetched with `pr view` and merged into the member list if GitHub’s label index hasn’t caught up yet, so the first add doesn’t report “batch (0): none”. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 0f357bf. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
…otfix) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jm3mCG9okfdGtAXtFaDF9A
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit fe12708. Configure here.
| "--json", "number,title,headRefName,headRefOid,url,labels,reviewDecision,mergeable,isDraft", | ||
| ]); | ||
| if (!row.labels.some((l) => l.name === NEVER)) list.push(row); | ||
| } |
There was a problem hiding this comment.
Stale index drops prior members
Medium Severity
When members() is still empty after label-index lag, rebuildAndReport only unions the PR passed as ensureNumber, not other PRs that already have the batch label. A second /batch can force-push a rollup that omits earlier members while those PRs keep the label, so the preview and rollup body no longer match the real batch.
Reviewed by Cursor Bugbot for commit fe12708. Configure here.
|
This pull request has conflicts with the base branch, please resolve those so we can evaluate the pull request. |


Why / What / How
Forward-port of #13534 to
dev(the bot executes master's copy — see that PR for the full analysis of the two live failures: refs-API 422 on unpushed objects, and the label-index race making the first /batch build nothing). Same two fixes applied to dev's copy ofbatch.mjs, preserving dev's #13521 hardening (exact-match ref check becomes moot — the whole refs-API block is replaced by the force-push).Changes 🏗️
.github/batch-bot/batch.mjs: force-push rollup branch; union just-added PR into the rebuildChecklist 📋
For code changes:
node --checkclean; same edits as fix(dx): batch bot — push rollup objects instead of refs-API update, fix add-then-list race #13534🤖 Generated with Claude Code
https://claude.ai/code/session_01Jm3mCG9okfdGtAXtFaDF9A
Note
Medium Risk
Changes core batch/rollup publishing and membership logic used in CI; misconfiguration could break previews or duplicate rollup PRs, but scope is limited to the bot script with documented GitHub API behavior.
Overview
Fixes two production failures in the batch bot’s rollup flow by changing how the ephemeral
batch/rollupbranch is published and how members are collected right after/batch.Rollup branch update: After assembling merges locally, the bot now force-pushes
HEADtorefs/heads/batch/rollupinstead of using the GitHub git refs API. Merge objects only exist in the Actions runner clone, so pointing a ref at them via API returned 422 “Object does not exist”; push uploads objects and moves the branch in one step.Rollup PR lookup:
gh pr list --headnow uses the plain branch name (batch/rollup), notowner:branch. The qualified form is ignored bypr list, so later rebuilds failed to find the existing rollup PR and tried to create duplicates.First
/batchrace:rebuildAndReportaccepts an optional PR number; when/batchjust added a label, that PR is fetched withpr viewand unioned into the member list if the label index hasn’t caught up yet—avoiding an empty first rebuild.Reviewed by Cursor Bugbot for commit fe12708. Bugbot is set up for automated code reviews on this repo. Configure here.