gh stack merge retries against an unmerged base PR, then silently rebases and dismisses approvals on the dependent PR

[joshuagraber]

Phase 1 — 3 failed attempts before anything merged (15:26–15:31 UTC):
Triggered "Squash and merge stack" from the PR #111 web panel three times. Each attempt logged a real auto_merge_disabled event on PR #111 only (15:26:58, 15:27:55, 15:30:34) — none on PR #104, the actual bottom-of-stack PR that must merge first. Per the README, gh stack merge is meant to be "all-or-nothing," but it appears to arm merge/auto-merge on the dependent PR before confirming the base PR has landed, hits an unresolved mergeable state, and aborts instead of waiting or retrying automatically — surfacing as a confusing "not mergeable" error with no indication that nothing had actually merged.

Phase 2 — merge manually, but silently strips approvals (15:35:23–15:35:29 UTC):
PR #104 squash-merged successfully. Immediately after:

• PR gh stack modify fails with untracked files #111 was rebased — all 3 commits got new SHAs with identical timestamps (a full rewrite, not just a base pointer change), then force-pushed.
• All 3 existing approving reviews were dismissed (confirmed via review_dismissed events), reverting reviewDecision to REVIEW_REQUIRED.
• Every CI check reset to pending.

Our org's ruleset has dismiss_stale_reviews_on_push: false — this dismissal happened regardless, because it was a history-rewriting force-push rather than an append-only push (which GitHub dismisses reviews for unconditionally). That's expected GitHub behavior for that specific push, but the push itself was an undisclosed side effect of the merge action — the PR content is byte-identical to what was approved, yet 3 reviewers now have to re-approve and CI has to fully rerun, with zero warning in the UI before this happened.

Ask: gh stack merge should either (a) confirm the base PR is actually merged before touching the dependent PR, and (b) warn — or offer a non-rebasing retarget path — before force-pushing an already-approved PR as a side effect of merging the layer beneath it.

[joshuagraber]

Update — reproduced a related but distinct failure mode on a separate, deeper (5-PR) stack in the same repo.

Stack: isubscribed/client-packages PR #105 → #106 → #107 → #108 → #109 (bottom to top).

After collecting approvals on all 5 PRs, confirmed via the API immediately beforehand that every PR was in a clean state:

#105 state=OPEN reviewDecision=APPROVED mergeable=MERGEABLE mergeStateStatus=CLEAN
#106 state=OPEN reviewDecision=APPROVED mergeable=MERGEABLE mergeStateStatus=CLEAN
#107 state=OPEN reviewDecision=APPROVED mergeable=MERGEABLE mergeStateStatus=CLEAN
#108 state=OPEN reviewDecision=APPROVED mergeable=MERGEABLE mergeStateStatus=CLEAN
#109 state=OPEN reviewDecision=APPROVED mergeable=MERGEABLE mergeStateStatus=CLEAN

Clicked "Squash and merge stack" from the PR #109 panel and got the same "Pull Request is not mergeable" error as in the original report. This time, checking GitHub's timeline for all 5 PRs immediately after showed zero new events of any kind — no auto_merge_disabled, no push, no merge, nothing. All 5 PRs remained byte-for-byte unchanged (same state, reviewDecision, mergeable, mergeStateStatus as pre-click).

This differs from the original report, where GitHub logged real auto_merge_disabled events on each failed attempt — meaning the request at least reached GitHub's API and was rejected there. Here there's no server-side footprint at all, which suggests the merge-stack UI/command may be evaluating mergeability/review-decision from stale cached PR state (plausibly cached from before approvals were collected) rather than re-querying current state before failing. Happy to share full repo/PR details for repro if useful.