You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When gh stack link fails partway through (see #373 for one way to trigger this), the stack's membership on GitHub is left altered rather than restored — PRs that were part of the stack before the failed call are silently dropped from it, with no rollback and no mention of this in the command's error output.
Repro
Build a stack main <- a <- b <- c <- d <- e via gh stack link. Confirm via gh api repos/{owner}/{repo}/stacks/{id} that all 5 PRs are listed under pull_requests.
Re-check the stack's membership: gh api repos/{owner}/{repo}/stacks/{id} --jq '.pull_requests[].number'.
Actual
Before step 3, the stack listed all 5 PRs. After the failed link call in step 3, the stack's pull_requests field lists only the merged PRs (a, b) — c, d, and e are gone from the stack entirely, even though d and e were never touched by the failed create attempt (only the lookup step "found" them, per #373's output).
This is also visible in the GitHub UI: PRs that previously showed a "Part of a stack" banner no longer show it at all.
I did not attempt to trigger this deliberately — it was an unwanted side effect discovered while working around #373 and #372.
Expected
Either:
The whole link operation should be atomic: a failure partway through (e.g. an individual PR-creation error) should not leave the stack's membership altered from before the call, or
If partial application is intentional/unavoidable, the command should clearly report which stack-membership changes actually took effect before it errored out, so the caller can reconcile the difference instead of discovering it later via the API or UI.
Environment
gh-stack version 0.0.8, installed via gh extension install github/gh-stack.
Summary
When
gh stack linkfails partway through (see #373 for one way to trigger this), the stack's membership on GitHub is left altered rather than restored — PRs that were part of the stack before the failed call are silently dropped from it, with no rollback and no mention of this in the command's error output.Repro
main <- a <- b <- c <- d <- eviagh stack link. Confirm viagh api repos/{owner}/{repo}/stacks/{id}that all 5 PRs are listed underpull_requests.aandb. Closecwithout merging.gh stack link a b c d e --base mainto fixd's base (see link doesn't recognize a branch's existing merged/closed PR, tries to create a duplicate #373) — it fails while trying to create a duplicate PR fora.gh api repos/{owner}/{repo}/stacks/{id} --jq '.pull_requests[].number'.Actual
Before step 3, the stack listed all 5 PRs. After the failed
linkcall in step 3, the stack'spull_requestsfield lists only the merged PRs (a,b) —c,d, andeare gone from the stack entirely, even thoughdandewere never touched by the failed create attempt (only the lookup step "found" them, per #373's output).This is also visible in the GitHub UI: PRs that previously showed a "Part of a stack" banner no longer show it at all.
I did not attempt to trigger this deliberately — it was an unwanted side effect discovered while working around #373 and #372.
Expected
Either:
linkoperation should be atomic: a failure partway through (e.g. an individual PR-creation error) should not leave the stack's membership altered from before the call, orEnvironment
gh-stackversion 0.0.8, installed viagh extension install github/gh-stack.