Summary
After a gh stack submit fails with the HTTP 422 from #428, the modify session state left in .git/gh-stack-modify-state keeps pointing at the old stack, so every subsequent gh stack submit retries the same impossible delete. The error tells you to "Run gh stack submit again to retry", but the retry can never succeed, and no CLI command clears the state. The only escape is deleting an internal file by hand.
This is separate from #428: that issue is about the 422 itself. This one is about being unable to recover from it.
Compounding it, the failed unstack is partially applied — the open PRs really are removed from the stack on GitHub — so the repository is left in a state that matches neither the local metadata nor the pre-submit state.
Reproduction
Starting from a submitted stack (#10) whose bottom layers are merged — #101, #102 merged; #103 → #104 → #105 open:
gh stack modify, insert a new branch mid-stack (between #103 and #104), Ctrl+S. The modify applies locally.
gh stack submit, answer Yes to "Overwrite the existing stack on GitHub?"
Checking stack state...
Skipping 2 merged branches
? The local stack has been modified. Overwrite the existing stack on GitHub? Yes
⚠ Failed to delete existing stack: HTTP 422: Pull requests #101, #102 cannot be removed from this stack (.../stacks/10/unstack)
Run `gh stack submit` again to retry
- Run
gh stack submit again — and again. Identical output every time.
The state that causes it
.git/gh-stack-modify-state:
{
"schema_version": 1,
"phase": "pending_submit",
"prior_remote_stack_id": "900001",
...
}
900001 is the internal id of stack #10. Every submit reads prior_remote_stack_id from this file and re-attempts the delete, which GitHub will never allow while the stack contains merged PRs.
Editing .git/gh-stack (removing the merged branch entries) does not help — the modify-state file is a second, independent store, and it is the one submit consults.
The partial unstack
After the first failed submit, GitHub's side had already changed:
$ gh api repos/OWNER/REPO/stacks
stack 10 open=false prs=[101, 102]
The open PRs #103, #104, #105 were successfully removed and now belong to no stack at all; only the two merged PRs remain. So unstack removed what it could and reported total failure. Local metadata still described all five.
Available exits, none of them good
gh stack submit — loops forever, as above.
gh stack modify --abort — would discard the completed mid-stack insertion, which is the work the user is trying to keep.
gh stack unstack 10 — cannot help; GitHub refuses to remove the merged PRs, which is the original 422.
- Editing
.git/gh-stack — no effect, wrong file.
rm .git/gh-stack-modify-state — the only thing that works.
After removing that file, gh stack submit succeeded immediately and did the right thing:
✓ Created PR #106 for <new-branch>
✓ Updated base branch for PR #104 to <new-branch>
✓ Stack created on GitHub with 4 PRs (stack #11)
Which shows the operation was viable all along — only the stale prior_remote_stack_id was blocking it.
Expected behavior
- When the delete fails with a 422 that cannot succeed on retry (merged PRs can never be removed from a stack), don't advise retrying. Fall back to creating a new stack, or say plainly that the old stack cannot be dissolved and offer that as a choice.
- Provide a supported way to clear a stuck
pending_submit modify state without discarding the applied modify — e.g. a counterpart to gh stack modify --abort such as --forget/--done that drops the session but keeps the local restructuring.
- Reconcile the partial unstack: if some PRs were removed and others refused, report that, and update local metadata to match what actually happened on the server.
Related
Environment
gh 2.97.0
gh-stack v0.1.0
- git 2.50.1 (Apple Git-155)
- macOS 26.6, darwin/arm64
Summary
After a
gh stack submitfails with the HTTP 422 from #428, the modify session state left in.git/gh-stack-modify-statekeeps pointing at the old stack, so every subsequentgh stack submitretries the same impossible delete. The error tells you to "Rungh stack submitagain to retry", but the retry can never succeed, and no CLI command clears the state. The only escape is deleting an internal file by hand.This is separate from #428: that issue is about the 422 itself. This one is about being unable to recover from it.
Compounding it, the failed
unstackis partially applied — the open PRs really are removed from the stack on GitHub — so the repository is left in a state that matches neither the local metadata nor the pre-submit state.Reproduction
Starting from a submitted stack (
#10) whose bottom layers are merged —#101,#102merged;#103 → #104 → #105open:gh stack modify, insert a new branch mid-stack (between#103and#104),Ctrl+S. The modify applies locally.gh stack submit, answerYesto "Overwrite the existing stack on GitHub?"gh stack submitagain — and again. Identical output every time.The state that causes it
.git/gh-stack-modify-state:{ "schema_version": 1, "phase": "pending_submit", "prior_remote_stack_id": "900001", ... }900001is the internal id of stack#10. Everysubmitreadsprior_remote_stack_idfrom this file and re-attempts the delete, which GitHub will never allow while the stack contains merged PRs.Editing
.git/gh-stack(removing the merged branch entries) does not help — the modify-state file is a second, independent store, and it is the onesubmitconsults.The partial unstack
After the first failed submit, GitHub's side had already changed:
The open PRs
#103,#104,#105were successfully removed and now belong to no stack at all; only the two merged PRs remain. Sounstackremoved what it could and reported total failure. Local metadata still described all five.Available exits, none of them good
gh stack submit— loops forever, as above.gh stack modify --abort— would discard the completed mid-stack insertion, which is the work the user is trying to keep.gh stack unstack 10— cannot help; GitHub refuses to remove the merged PRs, which is the original 422..git/gh-stack— no effect, wrong file.rm .git/gh-stack-modify-state— the only thing that works.After removing that file,
gh stack submitsucceeded immediately and did the right thing:Which shows the operation was viable all along — only the stale
prior_remote_stack_idwas blocking it.Expected behavior
pending_submitmodify state without discarding the applied modify — e.g. a counterpart togh stack modify --abortsuch as--forget/--donethat drops the session but keeps the local restructuring.Related
unstackreporting generic errors instead of the real API rejection.Environment
gh2.97.0gh-stackv0.1.0