Repository navigation
fix(source-control): pull-request merge must confirm the PR entered the merge queue #6630
Description
Observed 2026-10-07: gh pr merge <n> --squash on a merge-queue branch prints "The merge strategy for main is set by the merge queue". Sometimes the PR still does not enter the queue: #6481 sat CLEAN, with auto-merge armed and isInMergeQueue false, until it was queued directly with the GraphQL enqueuePullRequest mutation. #6426 needed the same check.
GitHub's docs say a PR joins the queue through the merge button or auto-merge (https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue). The merge phase (plugins/source-control/skills/pull-request/reference/merge.md) should:
- after
gh pr merge, readisInMergeQueue; - when the PR is CLEAN and not queued, run
enqueuePullRequest; - report the enqueue error verbatim. For example, "A conversation must be resolved" names the blocker.
Acceptance: a merge run either ends with the PR queued or merged, or names the blocker GitHub returned.
Activity
github-actions commentedon Oct 8, 2026
Understood:
gh pr merge --squashon a merge-queue branch can report success without the PR actually entering the queue (seen on #6481 and #6426), and the merge phase doc (plugins/source-control/skills/pull-request/reference/merge.md) doesn't verifyisInMergeQueueor fall back to theenqueuePullRequestGraphQL mutation when it's false. The request is scoped clearly: after merge, checkisInMergeQueue, enqueue directly when CLEAN-but-not-queued, and surface GitHub's enqueue error verbatim (e.g. an unresolved-conversation blocker) rather than failing silently. Acceptance criteria are already stated in the issue. No duplicates found in open issues. Nothing appears missing to act on this.Automated triage. A maintainer reviews it.
kyle-sexton commentedon Oct 11, 2026
Draft PR: #7075 (branch
fix/6630-merge-confirm-queue-entry).The merge phase gains §4.2.2 "Confirm queue entry": after
gh pr mergeon a merge-queue base it readsisInMergeQueue, enqueues aCLEANPR left out once withenqueuePullRequestat the head pinned in 4.1, and reports GitHub's refusal text verbatim, so a run ends merged, queued, or held with a named blocker. 4.2 and 4.2.1 point at it, and an armed auto-merge is reported.Verified with
bash -n, shellcheck, a stubbed-ghrun across 7 states,scripts/affected-tests.sh --base origin/main --run(plus the 2 selected Python suites, 48 passed), markdownlint and the changelog fragment checks.Left for a human: no live run against a real merge queue (GraphQL is refused from this session). Marking the PR ready waits for Kyle.
Generated by Claude Code
fix(source-control): pin merges to the head captured in 4.1 and warn …
kyle-sexton commentedon Oct 11, 2026
Handoff note for whoever picks this up next. The overnight Claude run has stopped, and Kyle is moving issue work to Cursor.
fix/6630-merge-confirm-queue-entryWhere a branch is listed it is pushed, so it can be taken over as is. A draft PR shows a red
ci-statusby design until it is marked ready.Generated by Claude Code