unstack shows a generic/incorrect error instead of the real API rejection reason
- 主要語言
- Go
- 星號
- 1.5k
- 分支
- 70
- 平均合併
- 1 天 8 小時
- 30 天內合併 PR
- 7
描述
## Summary
`gh stack unstack ` fails on a stack containing merged PRs, but the plain (non-debug) error message names an unrelated cause. The actual server-side reason is only visible with `GH_DEBUG=api`.
## Repro
1. Create a stack with `gh stack link` (or `submit`), e.g. `main <- a <- b <- c <- d <- e`.
2. Merge `a` and `b` (via merge queue or a normal merge — doesn't matter which).
3. Run `gh stack unstack ` on that stack.
## Actual
```
⚠ Some pull requests are queued for merge or have auto-merge enabled and remain stacked on GitHub
The stack was left in place — local tracking is unchanged
```
I verified via `gh api graphql` that **none** of the stack's PRs had `autoMergeRequest` set or a `mergeQueueEntry` — so the stated reason doesn't match reality.
Running the identical command with `GH_DEBUG=api gh stack unstack ` shows the real HTTP exchange:
```
POST /repos/{owner}/{repo}/stacks/{id}/unstack
< HTTP/2.0 422 Unprocessable Entity
{
"message": "Pull requests #.. , #.. cannot be removed from this stack",
"documentation_url": "https://docs.github.com/rest/pulls/stacks#remove-pull-requests-from-a-pull-request-stack",
"status": "422"
}
```
Interestingly, in the `GH_DEBUG=api` run the CLI's own final stderr line correctly echoed this specific message (`✗ Unstacking not allowed: Pull requests #.., #.. cannot be removed from this stack`) — a materially different, and accurate, explanation compared to the generic message shown without debug logging.
## Expected
The non-debug error message should reflect the actual REST API rejection (a stack can't be unstacked once any of its PRs have merged), not a generic, unrelated "queued for merge / auto-merge enabled" message.
## Environment
`gh-stack` version 0.0.8, installed via `gh extension install github/gh-stack`.
貢獻指南
研究方向
首先,在包含已合併 pull request 的 stack 上重現 `gh stack unstack `,並將一般輸出與 `GH_DEBUG=api` 下的輸出進行比較。追蹤 unstack 的錯誤處理以及 REST API 的 422 回應;完成的標準是,非除錯輸出報告實際的拒絕原因,而不是無關的 queued-for-merge 訊息。
由索引模型根據 Issue 內容生成。
評估
- 技術堆疊
- github, go
- 領域
- api, cli
- Issue 類型
- 缺陷
- 難度
- 3/5
- 預估耗時
- 1-2 天
- 活躍度
- 活躍
- 描述清晰度
- 基本清楚
- 新手友好度
- 67/100