fix(source-control): gh pr merge arms auto-merge instead of queueing when merge state is UNKNOWN #6953

Activity

1. github-actions

   added

   needs-triageNot yet classified. Floor until a type and one priority tier are set.Not yet classified. Floor until a type and one priority tier are set.

   on Oct 11, 2026
2. github-actions commented on Oct 11, 2026

   

   github-actionsbot

   on Oct 11, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for the report. Understood: gh pr merge called while mergeStateStatus is still UNKNOWN (right after a push or a ready flip) arms auto-merge instead of adding the PR to the merge queue, and this was observed repeatedly while landing the v2.1.265..v2.1.296 changelog PRs, requiring manual disarm/requeue. The ask is for the merge step to wait until mergeStateStatus settles before calling gh pr merge, and then confirm whether the PR was queued or auto-merge was armed rather than assuming.

   This looks related to #6630 (confirming the PR actually entered the merge queue after merge) and the now-closed #5953 (babysit --auto misreporting auto-merge as queued), but addresses a distinct root cause: the race against an unsettled mergeStateStatus rather than post-merge reporting. Worth checking those for overlap when scoping the fix.

   The report is otherwise complete — no missing information needed from my side.

   _{Automated triage. A maintainer reviews it.}
3. github-actions

   added

   priority: mediumReal value, no hard deadline; normal backlog flow.Real value, no hard deadline; normal backlog flow.

   on Oct 11, 2026
4. kyle-sexton

   removed

   needs-triageNot yet classified. Floor until a type and one priority tier are set.Not yet classified. Floor until a type and one priority tier are set.

   on Oct 12, 2026
5. kyle-sexton

   added the

   Bug

   issue type on Oct 12, 2026
6. kyle-sexton commented on Oct 13, 2026

   

   kyle-sexton

   on Oct 13, 2026

   ContributorAuthor

   More actions

   Decision recorded. The owner approved going with independently verified recommendations on 2026-10-13. Two researchers worked this issue separately (code and history; upstream docs and owner intent), and a judge reconciled them.

   • Close fix(source-control): gh pr merge arms auto-merge instead of queueing when merge state is UNKNOWN #6953 as a duplicate of fix(source-control): pull-request merge must confirm the PR entered the merge queue #6630 now? → No. On origin/main, only 4.2.1 (merge after AI review) requires CLEAN. The user-approved path (4.1, then 4.2) calls gh pr merge with no wait for a settled state. fix(source-control): confirm a merge-queue PR entered the queue after gh pr merge #7075 (the open draft for fix(source-control): pull-request merge must confirm the PR entered the merge queue #6630, currently CONFLICTING) adds 4.2.2, which runs after the merge call: it reads isInMergeQueue, mergeStateStatus and autoMergeRequest, warns when auto-merge is armed and holds. That catches an armed PR after it happens. It does not stop auto-merge from being armed while the state reads UNKNOWN.
     Basis: origin/main plugins/source-control/skills/pull-request/reference/merge.md:44-64 (4.2, no CLEAN wait) vs :66-104 (4.2.1 CLEAN gate); gh pr view 7075 (OPEN draft, CONFLICTING); gh pr diff 7075 (4.2.2 runs after gh pr merge; armed-auto-merge warning; hold on 'not queued and not CLEAN')
   • Is a pre-merge settle step needed, or is detection after the merge call enough? → A pre-merge step is needed. gh pr merge on a merge-queue base turns on auto-merge whenever required checks have not yet passed, and UNKNOWN means GitHub cannot yet say whether they have. Before any gh pr merge on a merge-queue base, re-read mergeStateStatus at the pinned head until it is no longer UNKNOWN. Call merge only on CLEAN; otherwise hold and report. Apply this on both the 4.2 path and the 4.2.1 path.
     Basis: gh pr merge --help, gh 2.102.0 (2026-09-30), run this session: 'If required checks have not yet passed, auto-merge will be enabled. If required checks have passed, the pull request will be added to the merge queue.'; fix(source-control): gh pr merge arms auto-merge instead of queueing when merge state is UNKNOWN #6953 intake-triage comment 2026-10-11T03:41 (the race against an unsettled mergeStateStatus is a distinct root cause)
   • Where should the fix go? → Into fix(source-control): confirm a merge-queue PR entered the queue after gh pr merge #7075 when it is rebased. It is the same plugin, the same file and the same issue family, so it shares one version bump and changelog fragment. Close fix(source-control): gh pr merge arms auto-merge instead of queueing when merge state is UNKNOWN #6953 as a duplicate of fix(source-control): pull-request merge must confirm the PR entered the merge queue #6630 once fix(source-control): confirm a merge-queue PR entered the queue after gh pr merge #7075 merges with the step. The change narrows when a merge call happens and adds no authority, so an agent can make it. Marking fix(source-control): confirm a merge-queue PR entered the queue after gh pr merge #7075 ready and merging it stay on the normal stop list.
     Basis: AGENTS.md (a small fix in the same plugin goes into the PR; marking ready is a stop); gh issue view 6630 (OPEN)

   Recommendation: Rebase #7075 onto main and add a pre-merge settle step to it: poll mergeStateStatus at the pinned head while it reads UNKNOWN, and merge only on CLEAN. Apply the step on both 4.2 and 4.2.1. Keep the 4.2.2 post-merge confirmation. Then close #6953 as a duplicate of #6630 when #7075 merges.

   Where sources disagreed, decided by: Rule 4 (current gh CLI manual: auto-merge is armed whenever required checks have not passed) over rule 5 (the record's 'close now, covered by #6678/#7075').

   Admission to an agent lane stays with the work-class rules and owner ratification.

   This was generated by AI.
7. kyle-sexton

   added a commit that references this issue on Oct 13, 2026

   Merge origin/main into fix/6630-merge-confirm-queue-entry

   ...

   fa28ecb
8. kyle-sexton commented on Oct 13, 2026

   

   kyle-sexton

   on Oct 13, 2026

   ContributorAuthor

   More actions

   Closing as a duplicate of #6630. #7075 merged and added the pre-merge step: before any merge call on a merge-queue base, it polls mergeStateStatus at the pinned head while it reads UNKNOWN, and merges or enqueues only on CLEAN. That covers this issue's race.
9. kyle-sexton

   closed this as a duplicateof fix(source-control): pull-request merge must confirm the PR entered the merge queue #6630 on Oct 13, 2026