Stack rebase left a PR unbuildable: test-merge ref points at an orphaned base commit

[mcmathews]

Summary

Scenario: a stack of two PRs rooted on main (bottom PR's base is main; top PR's base is the bottom PR's branch). An unrelated PR was merged into main, advancing the stack's trunk. We then used the "rebase stack" function to rebase the stack onto the updated main.

After that restack, the top PR in the stack was left in an unbuildable state: its server-side test-merge ref (refs/pull/N/merge) was computed against an old, now-orphaned base commit rather than the current tip of its base branch (the bottom PR's branch, which the restack had moved). CI that builds PRs from the merge ref then fails, and the state can't be recovered from the PR UI.

Observed behavior

After the "rebase stack" completed:

• The top PR's REST base.sha correctly reflected the new tip of its base branch.
• However, the commit used to compute that PR's test-merge ref (refs/pull/N/merge) remained an earlier base commit that was no longer reachable on the remote (an intermediate/pre-restack commit of the base branch).
• The precomputed merge commit therefore had that orphaned commit as one of its parents.
• CI that builds PRs from refs/pull/N/merge (for example Jenkins' GitHub Branch Source "merge with target branch" strategy) fetches only reachable refs, so the orphaned base commit isn't present, and the checkout/merge fails with merge: <sha> - not something we can merge.
• The stale state persisted across repository re-scans and even closing/reopening the PR (reopening recomputed the merge, but still against the orphaned commit). Retargeting the PR's base branch was what finally forced the merge ref to re-resolve.

Why it matters

Rebasing a stack onto an advanced trunk is a routine, expected operation, so if "rebase stack" can leave an affected PR's merge ref pointing at an orphaned base commit, the top of a stack can get wedged into an unbuildable state after an otherwise-successful restack — with no obvious recovery from the PR UI. It's easy to miss because the PR's displayed base.sha looks correct; only the merge-ref computation is stale.

Request

Could you confirm whether "rebase stack" is expected to invalidate/recompute each affected PR's test-merge ref against the new base tip? It would help if restacking guaranteed each PR's merge parent is always a reachable commit consistent with the updated base.sha.

We're not certain of the exact trigger — whether it's specific to the "rebase stack" function or a more general base-update edge case — but it reproduced right after using "rebase stack" to rebase a stack onto an updated main. Happy to provide a concrete reproduction (repository, PR numbers, before/after SHAs, and CI logs) if that would help — feel free to reach out.