Repository navigation
fix(stack): discover a stack's pull requests without the Search API - #1862
Merged
Conversation
`stack push`, `list`, `sync` and `checkout` found a stack's pull
requests with `GET /search/issues`. Environments that only allow
repository-scoped API paths answer that with a 403, so every remote
stack command failed there. Claude Code on the web's GitHub proxy is
one of them.
Discovery now uses only `/repos/{owner}/{repo}/...` endpoints:
1. `GET /git/matching-refs/heads/<prefix>/` lists every branch under
the stack prefix in one call, with no pagination. I checked this
against a repository holding 1,308 matching branches. Only
branches one segment below the prefix whose name ends in a
Change-Id are kept, which is the shape `stack push` creates.
2. For each local commit whose Change-Id is on no live branch, the
branch it would be pushed to (`<prefix>/<slug>`) is added. This is
how a merged PR is still found after GitHub deleted its branch.
`stack sync` needs that PR to drop the commit. The merged state only
counts when the PR's `head.sha` equals the local commit, and an
unchanged commit has an unchanged title, so its slug is the branch
it was pushed under.
3. `GET /pulls?head=owner:<branch>&state=all` runs once per branch.
That filter reads the PR's recorded head, so it also returns closed
and merged PRs whose branch is gone. I checked this on a merged PR
whose branch had been deleted.
4. Results are sorted by `updated_at`, newest first, the same order
the search used, then grouped by Change-Id as before. The author
filter runs locally on `user.login`, case-insensitively like
`author:` was.
Why not one paginated `GET /pulls` listing filtered by head prefix?
Its cost grows with the number of open PRs in the repository, not
with the size of the stack. It also misses merged PRs, and those
would still need step 2. The approach above costs one call plus one
per branch. The old one cost one search call plus one per PR.
Search is not kept as a fallback. The only thing it could still find
is a merged PR whose branch is deleted and whose Change-Id is no
longer in the local stack. Nothing reads that PR: orphans are
reported only when open. Search also has its own small rate limit and
an index that lags behind new PRs, which the repository endpoints do
not.
The payloads now come from the list endpoint. It carries everything
downstream reads, including the native `stack` object, except
`mergeable`. `stack list` therefore fetches each unmerged PR itself
for its `(conflicting)` marker, as part of its CI and review fan-out.
`stack open` skips that, as it skips the fan-out.
Fixes #1861
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: Ibd22adea3084f027d64718be8fa6f331a7cb9b9b
Contributor
Merge Protections🟢 All 6 merge protections satisfied — ready to merge. Show 6 satisfied protections🟢 🤖 Continuous Integration
🟢 👀 Review Requirements
🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 🔎 Reviews
🟢 📕 PR description
🟢 🚦 Auto-queueWhen all merge protections are satisfied, this pull request will be queued automatically. |
jd
marked this pull request as ready for review
October 1, 2026 14:13
sileht
approved these changes
Oct 1, 2026
kozlek
approved these changes
Oct 1, 2026
Contributor
Merge Queue Status
This pull request spent 8 minutes in the queue, including 7 minutes 30 seconds running CI. Required conditions to merge
|
34 of 40 tasks
mergify
Bot
deleted the
devs/jd/jd/stack-discovery-without-search/discover-stack-s-pull-reqs-without-search-api--bd22adea
branch
October 1, 2026 16:22
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
stack push,list,syncandcheckoutfound a stack's pullrequests with
GET /search/issues. Environments that only allowrepository-scoped API paths answer that with a 403, so every remote
stack command failed there. Claude Code on the web's GitHub proxy is
one of them.
Discovery now uses only
/repos/{owner}/{repo}/...endpoints:GET /git/matching-refs/heads/<prefix>/lists every branch underthe stack prefix in one call, with no pagination. I checked this
against a repository holding 1,308 matching branches. Only
branches one segment below the prefix whose name ends in a
Change-Id are kept, which is the shape
stack pushcreates.branch it would be pushed to (
<prefix>/<slug>) is added. This ishow a merged PR is still found after GitHub deleted its branch.
stack syncneeds that PR to drop the commit. The merged state onlycounts when the PR's
head.shaequals the local commit, and anunchanged commit has an unchanged title, so its slug is the branch
it was pushed under.
GET /pulls?head=owner:<branch>&state=allruns once per branch.That filter reads the PR's recorded head, so it also returns closed
and merged PRs whose branch is gone. I checked this on a merged PR
whose branch had been deleted.
updated_at, newest first, the same orderthe search used, then grouped by Change-Id as before. The author
filter runs locally on
user.login, case-insensitively likeauthor:was.Why not one paginated
GET /pullslisting filtered by head prefix?Its cost grows with the number of open PRs in the repository, not
with the size of the stack. It also misses merged PRs, and those
would still need step 2. The approach above costs one call plus one
per branch. The old one cost one search call plus one per PR.
Search is not kept as a fallback. The only thing it could still find
is a merged PR whose branch is deleted and whose Change-Id is no
longer in the local stack. Nothing reads that PR: orphans are
reported only when open. Search also has its own small rate limit and
an index that lags behind new PRs, which the repository endpoints do
not.
The payloads now come from the list endpoint. It carries everything
downstream reads, including the native
stackobject, exceptmergeable.stack listtherefore fetches each unmerged PR itselffor its
(conflicting)marker, as part of its CI and review fan-out.stack openskips that, as it skips the fan-out.Fixes #1861
Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com