Repository navigation
fix(pr-pipeline): read auto-merge state back when a resent arm or disarm errors #9547
Description
Problem
.github/scripts/pr-merge/enable-auto-merge.mjs resends an arm or disarm mutation after a transient network error. If the first attempt reached GitHub but its answer was lost, the resend can return an error even though the pull request already holds the target state. GitHub does not document how enablePullRequestAutoMerge answers on an already-armed pull request (https://docs.github.com/en/graphql/reference/pulls). The step then exits 1 on a correct outcome. A red pr-merge run counts toward the two-failure revert rule and the gate-repeat alert, so it is false evidence.
Fix
When a resent arm or disarm returns an error, read the pull request's autoMergeRequest once. Count it a success when the state already matches the target: armed at the same head for an arm, unarmed for a disarm.
Done when
- A resend that errors after a lost first answer, with the pull request already in the target state, logs a success and does not fail the step.
- A resend that errors while the state does not match still fails, naming the pull request and the cause.
- Tests cover both cases.
Activity
github-actions commentedon Oct 24, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Medium
Uncertainty: Known
Flags: none
Blocked by: none
Understood: when enable-auto-merge.mjs resends an arm or disarm after a transient network error and the resend returns an error, the step should read autoMergeRequest back once. It should log success if the state already matches the target (armed at the same head, or unarmed) and fail otherwise, naming the pull request and the cause. Tests should cover both cases. The scope and done-when items are clear and checkable. I found no likely duplicates.
Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Oct 24, 2026
The work-resolve-issue lane did not start this issue: it needs a person to make it clearer first.
Why, in the run's own words:
What the run says it did not do:
Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/40054893459
To retry, answer the question here, remove
needs-humanand addagent-readyagain.kyle-sexton commentedon Oct 25, 2026
Re-checked on main (2d9ac7f): the earlier pushback's premise, that nothing resends the arm/disarm mutation, came from lane run 40054893459, which started at 02:36Z on a base older than #9545 (merged 03:58Z). On main,
withRetryin.github/scripts/pr-merge/enable-auto-merge.mjs:197-241resends both GraphQL POSTs on network errors, the comment at:214-218describes this issue's bug, and the catch at:872-904never readsautoMergeRequestback. The issue stands as written; releasing it for re-triage.kyle-sexton commentedon Oct 26, 2026
Released for re-triage under the owner's 2026-10-26 rule: a person is involved only for "1. A change in original intent/vision 2. Something comes up during implementation ... that alters intent/vision or the primary design 3. If there is a HIGH/CRITICAL security issue". None applies here, so the hold label came off and intake triage runs again now.
To hold this issue again, add
needs-human(orstatus: needs-decision) and name which of the three applies.kyle-sexton commentedon Oct 26, 2026
Released for re-triage under the owner's 2026-10-26 rule: a person is involved only for "1. A change in original intent/vision 2. Something comes up during implementation ... that alters intent/vision or the primary design 3. If there is a HIGH/CRITICAL security issue". None applies here, so the hold label came off and intake triage runs again now.
To hold this issue again, add
needs-human(orstatus: needs-decision) and name which of the three applies.