Summary
Using gh stack link to add PRs to a stack fails when an existing stack contains a PR that is queued for merge. The CLI reports that the queued PR "cannot be added to a stack: it is queued for merge" for the queued PR even when that queued PR is already part of the target stack, preventing the operation from succeeding.
Reproduction steps
- Have an existing stack of PRs where the first PR is already in the merge queue.
- Open additional PRs on top of that stack via the Web UI (or otherwise) but do not add them to the stack.
- Run: gh stack link https://github.com/github/github/pull/439655 https://github.com/github/github/pull/439657 https://github.com/github/github/pull/439717 https://github.com/github/github/pull/440024
Observed behavior
The command fails with:
✗ PR #439655 cannot be added to a stack: it is queued for merge
Even though PR #439655 is already part of the existing stack and the queued PR being in the queue should not block linking new PRs into that same stack.
Expected behavior
Queued PRs that are already part of the target stack should not cause gh stack link to fail. The operation should succeed and add the specified PRs to the existing stack (or skip ones already in the stack) unless there is another valid reason to fail.
Notes / context
Slack thread excerpt:
"Possible CLI bug: I opened a PR on top of an existing stack through the Web UI but forgot to add it to my stack. The first PR in the stack is in the merge queue, but is already part of the stack. This seems to prevent me from adding to the stack. ... hmm this is actually by design. i have a check to prevent adding to a stack where there aren't any open PRs ... I yanked two of the PRs out of the queue, so only the first one is queued and the 2nd and 3rd aren't. Same result: ... ah i see, yup that's def a bug. queued PRs in the existing stack should not be causing that to fail"
Suggested fix
When evaluating whether a PR can be added to a stack, ignore queued PRs that are already members of the target stack. Only treat queued PRs as blocking when they are not already part of the stack being modified. Alternatively, detect and explicitly skip PRs that are already in the stack rather than failing the whole operation.
Environment
Additional notes
Reported by: skarim (Slack conversation)
View original Slack conversation
Summary
Using gh stack link to add PRs to a stack fails when an existing stack contains a PR that is queued for merge. The CLI reports that the queued PR "cannot be added to a stack: it is queued for merge" for the queued PR even when that queued PR is already part of the target stack, preventing the operation from succeeding.
Reproduction steps
Observed behavior
The command fails with:
✗ PR #439655 cannot be added to a stack: it is queued for merge
Even though PR #439655 is already part of the existing stack and the queued PR being in the queue should not block linking new PRs into that same stack.
Expected behavior
Queued PRs that are already part of the target stack should not cause gh stack link to fail. The operation should succeed and add the specified PRs to the existing stack (or skip ones already in the stack) unless there is another valid reason to fail.
Notes / context
Slack thread excerpt:
"Possible CLI bug: I opened a PR on top of an existing stack through the Web UI but forgot to add it to my stack. The first PR in the stack is in the merge queue, but is already part of the stack. This seems to prevent me from adding to the stack. ... hmm this is actually by design. i have a check to prevent adding to a stack where there aren't any open PRs ... I yanked two of the PRs out of the queue, so only the first one is queued and the 2nd and 3rd aren't. Same result: ... ah i see, yup that's def a bug. queued PRs in the existing stack should not be causing that to fail"
Suggested fix
When evaluating whether a PR can be added to a stack, ignore queued PRs that are already members of the target stack. Only treat queued PRs as blocking when they are not already part of the stack being modified. Alternatively, detect and explicitly skip PRs that are already in the stack rather than failing the whole operation.
Environment
Additional notes
Reported by: skarim (Slack conversation)
View original Slack conversation