Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

A failed link call leaves the target stack's membership partially mutated

Open
#374 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
github, go
Domain
api, cli

Research direction

Start with the gh stack link command and reproduce the failure using the steps in this issue, then inspect the calls affecting repos/{owner}/{repo}/stacks/{id} membership. Trace how a failed PR-creation attempt handles earlier and later membership changes. Done means a failed link either preserves the original pull_requests membership or clearly reports every partial change, with verification against the API.

Written by the indexing model from the issue text.

Description

bug topic: cli - link

Summary

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

  1. 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.
  2. Merge a and b. Close c without merging.
  3. Run gh stack link a b c d e --base main to fix d's base (see #373) — it fails while trying to create a duplicate PR for a.
  4. 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.

Dominant language
Go
Stars
1.5k
Forks
73
Avg merge
1d 8h
Merged PRs (30d)
7

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/gh-stack

All issues in github/gh-stack

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.