gh stack submit falsely reports stack recreation when no replacement stack is persisted

Bắt đầu với luồng gh stack submit và tái hiện trạng thái được báo cáo bằng các kiểm tra gh api không dùng bộ nhớ đệm cho stack và một PR đang mở. Theo dõi việc tái tạo stack thông qua việc lưu trữ trên remote và các cập nhật cục bộ của .git/gh-stack. Hoàn tất có nghĩa là các lỗi trả về giá trị khác không, trong khi thành công chỉ được in ra sau khi stack thay thế và tư cách thành viên PR được mong đợi đã được xác minh.

Summary

gh stack submit reports that a modified stack was successfully recreated on GitHub, but no replacement stack exists afterward.

Branches and PR bases are pushed successfully. Open PRs become unstacked, local metadata retains the old closed stack ID, and the command still exits with success output.

Environment

• gh version 2.97.0
• gh stack version 0.1.0
• macOS 26.6
• Repository has GitHub Stacks enabled

Setup

Existing remote stack:

• One merged bottom PR
• Multiple open PRs
• One closed PR in the middle

Locally:

1. Check out remote stack.
2. Run gh stack modify.
3. Drop the closed middle PR.
4. Resolve cascading rebase conflicts.
5. Run gh stack submit.

Actual output

Found the stack on GitHub — updating it to match your local stack
Merged PRs have left the stack on GitHub, so it wasn't updated — your unmerged PRs were pushed and re-based onto the trunk
✓ Stack recreated on GitHub to match local state
✓ Pushed and synced 47 branches

Actual remote state

The branches were pushed, but no replacement stack was created.

Repeated uncached API checks showed:

gh api -H 'Cache-Control: no-cache' \
  repos/OWNER/REPO/pulls/OPEN_PR \
  --jq '.stack'

Result:

null

Listing repository stacks showed only the old closed stacks:

gh api -H 'Cache-Control: no-cache' \
  'repos/OWNER/REPO/stacks?per_page=100'

The old stack remained closed with only its merged PR. No new stack number appeared.

This was checked three times over 12 seconds. Direct PR membership and the stack list remained unchanged.

Local .git/gh-stack still referenced the old closed stack number and ID.

Expected behavior

One of:

1. A replacement remote stack is persisted and local metadata is updated to its new number and ID.
2. Stack creation failure is reported with a non-zero exit code.

The command must not print:

✓ Stack recreated on GitHub to match local state

unless the remote stack exists and its PR membership has been verified.

Impact

• User believes stack recreation succeeded.
• GitHub UI contains no open stack.
• Every open PR has stack: null.
• Local metadata points to a closed historical stack.
• Subsequent checkout, sync, and modify operations begin from inconsistent state.

Suggested safeguard

After creating or recreating the stack:

1. Read the returned stack ID and number.
2. Query the stack or one member PR.
3. Verify expected membership.
4. Only then persist local metadata and print success.

If verification fails, retain recovery state and return an error.