Merge queue removes stacked child PRs with invalid_merge_commit under squash merge method

[laurynasgrape]

Summary

With a merge queue configured to squash merging, enqueueing a native stack via "Enqueue stack" reliably fails: the bottom PR (base = default branch) stays queued, but the stacked child is removed within ~15–20 seconds with reason invalid_merge_commit (UI: "github-merge-queue bot removed this pull request from the merge queue due to invalid changes in the merge commit"). The removal happens before any checks complete, so it looks like merge-commit validation rather than a CI failure.

The overview docs state that squash merges are fully supported for stacks and that merging a stack is a single atomic operation, so this appears to be a bug rather than a documented limitation.

Setup

• Private org monorepo, merge queue required for all merges into main
• Merge queue configuration: mergeMethod: SQUASH, mergingStrategy: ALLGREEN (squash is the only merge method allowed on the repo)
• Native stacked PRs (created/tracked with the gh-stack CLI extension): a 3-PR stack, PR-1 → PR-2 → PR-3
• PR-1 had already merged; PR-2 (base main) and PR-3 (base = PR-2's branch) were both approved with all checks green, and the stack view showed "Able to merge as a stack" with an "Enqueue stack 2" button

Expected

Clicking "Enqueue stack" merges PR-2 and PR-3 atomically through the queue, each as its own squash commit.

Actual

Both PRs enter the queue; seconds later the child is kicked. RemovedFromMergeQueueEvent timeline data (via GraphQL) across two days, six attempts:

• Attempts 1–5 (while an earlier parent was the bottom of the queued stack): the queued parent was removed with invalid_merge_commit ~15 s after AddedToMergeQueueEvent, and the child cascaded out with stack_out_of_order.
• Attempt 6 (after the original bottom PR had merged): the new bottom PR (base main) stayed queued in AWAITING_CHECKS, and the child was removed with invalid_merge_commit 17 s after being added — while its parent was still unmerged in the queue.

In every case the removed PR reported mergeable: MERGEABLE / mergeStateStatus: CLEAN immediately afterwards.

Workaround

Serial enqueueing works every time: let the bottom PR merge through the queue, wait for the child to retarget to main and get rebased, then enqueue it alone. Only the multi-entry "Enqueue stack" path fails.

Hypothesis

Under squash, the queue appears to build and validate the child's speculative merge commit against a base state that doesn't yet include the parent's squashed result (the child branch still carries the parent's pre-squash commits), so the validation "changes in the merge commit match the PR" fails. The stack-aware rebase that makes serial merging work doesn't seem to happen before the in-queue validation of later stack entries.

Happy to share repo/PR identifiers and exact timestamps privately if useful for debugging.