`gh stack submit` fails after modifying a partially-merged stack

[cmolder]

Problem

After running gh stack modify, gh stack submit dissolves the old remote stack (via an unstack call) and recreates it. If the old stack contained merged PRs, gh stack submit aborts with this (incorrect) error:

✗ the previous stack still has pull requests queued for merge or with auto-merge enabled; it cannot be recreated yet

despite nothing being queued and no PR having auto-merge enabled.

GitHub never removes merged PRs from a stack, so the unstack call can't dissolve it. Instead, it releases every open PR and returns the leftover stack, which holds only merged PRs. Consequently, gh stack submit reads any non-dissolved response as "a PR is queued" and stops.

Example

Consider a stack main <- A <- B <- C where:

• A is merged
• B and C are open

Then do the following:

1. Run gh stack modify and swap B and C.
2. Run gh stack submit.

gh stack submit asks to overwrite the existing stack, then calls unstack on the old one. GitHub releases B and C but keeps A, since merged PRs stay in a stack as history. The call returns the remaining stack (A only) instead of dissolving it. Submit sees "not dissolved", assumes a queued PR, and exits with the error above.

However, at this point the unstack is already partly applied. The journal still points at the old stack, so retrying gh stack submit makes the same call and hits the same error.

Related issues

• submit loops forever after a failed stack delete: stale pending_submit modify state has no supported way out #433, where a stuck pending_submit journal loops forever.
• HTTP 422 when resubmitting a stack with a new bottom branch after merge #428, but this reports an HTTP 422 error duringthe unstack call. By contrast, in this issue, the call succeeds and the leftover stack is misread.

Fix

I wrote a fix in one commit, on top of v0.2.0:

• e38203c let submit proceed when only merged PRs remain after unstack

Changes:

1. cmd/submit.go:
   • Keep the leftover stack from Unstack in handlePendingModify instead of discarding it.
   • Add onlyMergedPRsRemain. When the leftover stack holds only merged PRs, continue with recreation.
   • Keep the "queued for merge" error when an open PR remains, or when the leftover stack isn't reported, since either may mean a real queued PR.
2. cmd/submit_test.go:
   • Add TestPendingModify_OnlyMergedPRsRemainProceeds.
   • Add TestPendingModify_OpenPRRemainsPreservesState, which guards the error for a real open PR.

The first test fails on main and passes with the fix. The second passes on both, and exists to ensure the error is preserved for PRs that are actually queued.

I would open a PR for this but it's locked to contributors only. Full disclosure: I used Claude to identify and write the fix, but I manually reviewed and edited it afterwards.

Result

After gh stack modify, gh stack submit rebuilds the stack, even when the old stack has merged PRs. The "queued for merge" error only appears when an open PR remains.