"Merge stack" on a stacked PR appears to enqueue only the bottom PR

[annyzhou]

Summary

When a repository requires GitHub Merge Queue on the trunk branch, clicking "Merge stack" on a stacked PR appears to enqueue only the bottom PR. The UI says the stack can be merged together, but the merge queue only recognizes the PR whose base is the protected trunk branch.

Repro

1. Create a stack:
   • PR A targets dev
   • PR B targets PR A's branch
2. Ensure both PRs are approved, green, and linear.
3. Open PR B.
4. GitHub shows "Able to merge as a stack" and "Merge stack 2".
5. Click "Merge stack".

Expected behavior

Either:

1. The entire eligible stack is merged/queued correctly, or
2. The UI explains that merge queue can only queue the bottom PR and the rest must be merged after each lower layer lands.

Actual behavior

Only the bottom PR is recognized by merge queue. The upper PR remains unmerged and must be merged manually after the lower PR lands.

Why this is confusing

The button says "Merge stack" and shows a count of PRs, which implies the stack will merge as a unit. With required merge queue, the actual behavior is one-layer-at-a-time.

FYI, our merge queue config is fine:

• max_entries_to_build: 5
• min_entries_to_merge: 1
• max_entries_to_merge: 3
• strategy: ALLGREEN

[windsornguyen]

Reproduced with merge queue and latest-push approval enabled: the bottom PR merged, GitHub rebased the upper PR and invalidated its approval, the upper PR was never queued, and the merge dialog kept spinning. Minimal repro: #174.

[windsornguyen]

Additional evidence from a five-PR reproduction:

• Client: gh 2.95.0 and gh-stack 0.0.7.
• Repository requires squash merge queue; queue config was ALLGREEN, build concurrency 5, maximum merge size 3.
• All five PRs were approved, green, linear, and shown as eligible for Merge stack 5.
• Clicking it placed all five PRs in the queue in the correct bottom-to-top order.
• The bottom PR merge-group check passed and that PR squash-merged.
• GitHub then automatically rebased/force-pushed the four remaining stack branches, but removed their queue entries instead of continuing the stack.
• The remaining PRs had identical patch IDs before and after the rewrite, correct linear ancestry, MERGEABLE state, and retained APPROVED review decisions. The displayed merge conflicts were therefore transient queue/stack state, not source conflicts.

A five-PR stack exceeds the configured maximum of 3 plus the documented 50% stack buffer, so splitting it across groups is expected. The FAQ says the remaining PRs should continue in subsequent groups; instead, the operation stopped after the first PR.

This looks like the server-side stack landing operation losing or invalidating downstream queue entries when their head OIDs are rewritten after the first squash merge. It is broader than approval invalidation alone. Related minimal issue: #174