gh stack submit fails trying to unstack an unrelated, permanently-closed stack

[avx-wlauer]

Summary

gh stack submit fails trying to delete/unstack a completely unrelated, already-closed stack that contains a merged PR -- even when that stack has zero overlap with the branches/PRs actually being submitted.

Environment

• gh stack v0.1.1 (latest per gh extension list / gh extension upgrade)
• Windows 11, PowerShell 7.6.5
• Private repo, gh CLI authenticated as repo collaborator

Error

Checking stack state...
Failed to delete existing stack: HTTP 422: Pull request #3149 cannot be removed from this stack (https://api.github.com/repos/OWNER/REPO/stacks/3151/unstack)
Run `gh stack submit` again to retry

Repro

1. Repo has an old, fully-closed stack (stack A) whose only PR was merged long ago. Since merged PRs can never be removed from a stack (per https://docs.github.com/rest/pulls/stacks#remove-pull-requests-from-a-pull-request-stack), stack A is permanently closed but can never fully dissolve.
2. Create a brand-new, completely unrelated stack (stack B) via gh stack link branch1 branch2 --open, then attach local tracking with gh stack checkout <stack B number>.
3. Run gh stack submit --auto --open against stack B -- no code changes, just re-submitting branches that already have open PRs and correct local tracking.
4. submit immediately fails trying to delete stack A, which shares no PRs or branches with stack B at all.

What we ruled out

• Not local-tracking-file related. Reproduces identically whether .git/gh-stack is deleted, hand-edited, or freshly (re)imported via gh stack checkout.
• Not related to which PR/branch is being submitted. Reproduces against a brand-new stack with fresh PR numbers that never touched the old stuck stack.
• Not a GitHub API bug. Called the raw REST endpoint directly (POST /repos/OWNER/REPO/stacks/{number}/unstack) and got the same 422 -- this is GitHub's documented, correct behavior for a stack containing a merged PR. The bug is that gh stack submit is calling unstack on the wrong (unrelated) stack at all.

Impact

Once any stack in a repo becomes permanently closed with an unremovable merged PR -- which happens naturally the first time a single-PR stack's PR merges and nothing more is added to it -- gh stack submit appears to become unusable repo-wide, for any stack, from then on.

We also found this failure mode is easy to accidentally create: closing (not merging) the remaining open PRs in an otherwise-healthy stack has the same effect. POST stacks/{number}/unstack strips out the closed-but-unmerged PRs and leaves the already-merged one behind permanently stuck -- silently turning a normal stack into another landmine.

Workaround

gh stack link <branch/PR bottom-to-top> + gh stack checkout <number> works fine for creating/growing a stack, and plain git push works for pushing new commits to branches with existing open PRs. gh stack submit is the only command we've found that reliably fails once a repo has one of these permanently-closed stacks.

[benjooom]

I hit the same gh stack submit failure: a fresh stack failed trying to unstack an unrelated, stale stack. I did find something that might be a related clue, though.

While trying to rename a branch in this fresh stack, gh stack modify refused to open the TUI and errored immediately with:

✗ a modify was completed but the stack has not been submitted yet
Run `gh stack submit` to push changes and recreate the stack on GitHub

even though no rename had happened yet.

I manually deleted .git/gh-stack-modify-state and then gh stack modify worked normally letting me rename the branch.

I then tried gh stack submit which also surprisingly succeeded without the original unstack error.

For me, gh stack submit works on all stacks now.

I can't be certain the two are connected, but still seems worth flagging: is it possible .git/gh-stack-modify-state (rather than .git/gh-stack) is involved in how submit decides which stack to overwrite? Posting in case it helps narrow down the repro, or in case others hitting the unstack error also have a stale modify-state file lying around.