You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(server): a branch's own pull request shows past a hundred same-named fork pull requests - #32796
A branch loses its pull request in T3 when more than 100 newer pull requests from other forks use the same branch name. The git actions control shows no pull request, so its pull request actions are gone too. Busy repositories hit this with common names: a fork's main or master, or GitHub's web-edit default patch-1. For example, DefinitelyTyped/DefinitelyTyped has about 15,000 pull requests from heads named master, and MicrosoftDocs/azure-docs has about 12,000 from patch-1. A pull request open for a few days in such a repository falls out of the newest 100.
Branch status looks the pull request up by the bare branch name: one page of the 100 newest pull requests in any state, then GitManager keeps the rows whose head repository is the branch's own. #13200 chose this so that "same-named branches on other forks can no longer crowd out the real match". Once more than 100 newer same-named pull requests exist, that page holds only other forks' rows and nothing matches. Open pull requests are far fewer (tens at most on those repositories), so the open-only lookup that Create PR already uses still finds it.
Change
In GitManager.findLatestPrForHeadContext, when an all-states page comes back full and holds no open match, look the branch up once more with the existing open-only lookup (findOpenPr) and use its result. A page that is not full, or one with an open match, makes the same single request as today. The provider, its query and the head probe are unchanged.
Scope and approval
This is a very small, focused fix for an obvious bug, so it comes without a prior issue. It makes the lookup #13200 designed hold past its first page, using a lookup that already exists, with no new setting, query or UI. It covers every host through the same code; GitHub and Azure DevOps use the 100-row probe.
Left as is: a branch whose own pull request is closed or merged, with more than 100 newer same-named pull requests, still shows none. Finding it would need paging the bare branch name across all states, which can mean thousands of rows.
Verification
Test, a new case in apps/server/src/git/GitManager.test.ts: a fork branch whose all-states page holds 100 closed pull requests from other forks, and whose open lookup returns its own pull request.
vp test run apps/server/src/git/GitManager.test.ts -t "finds a fork branch's open PR past a full page of other forks' PRs" on main: fails with expected null to match object { number: 1, state: 'open' }. With the fix: passes, and the listings asked for ["all", "open"].
The whole file passes with the fix (126 tests), and vp run check:changed passes.
Web, against a local stub GitHub Enterprise API on loopback serving the fake repository acme/web: 129 merged or closed pull requests from forks fork-2 to fork-130 on head patch-1, created after the repository's own open pull request #1 on the same head. The project is a local checkout on branch patch-1.
Before (main): the git actions control on patch-1 offers "Create PR" and shows no pull request. The stub's log has one lookup for patch-1, all states, first 100, which returns #130 to #31.
After (this branch): the same view shows "#1: Update the getting started g…" and the pull request chip below the composer. The log has the same all-states lookup, then an open-only lookup that returns #1.
Not checked:
Desktop and mobile were not run. They read the same branch status from the same server code.
Real GitHub; the stub runs GitHub's query shape with fake data.
…med fork pull requests
Branch status looks a branch's pull request up by its bare head name, one
page of 100 across all states, and keeps rows whose head repository matches.
When more than 100 newer pull requests from other forks reuse that head name
(common for `main` or `patch-1` on busy repositories), the page holds only
their rows and the branch's own open pull request never shows.
When an all-states page comes back full and holds no open match, look the
branch up once more among open pull requests only and use that result. Pages
that are not full make no extra request.
Macroscope's review found this PR approvable — This adds an open-PR lookup fallback when same-named fork PRs fill the initial results page. Existing repository matching remains in place, and the additional queries are read-only.
You can add or adjust custom eligibility rules. Learn more.
No actionable comments were generated in the recent review.
Walkthrough
The pull request changes fork pull request lookup to retry with an open-state query when an all-states query returns a full page. A regression test covers finding a matching open pull request from a fork on the subsequent query.
findLatestPrForHeadContext tracks whether a query returns a full page. If no matching open pull request is found, it calls findOpenPr when a page was full. The regression test checks that the matching fork pull request is returned and that queries use all followed by open.
The full-page lookup fallback has a targeted regression test. No actionable issue remains identified before merge.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title names the main change: a branch's own pull request now shows past more than a hundred same-named fork pull requests. The raw summary and objectives confirm the change adds a retry through th…
Description check
The description follows the template. It has Problem, Change, Scope and approval, and Verification sections. The Problem section gives the bug, the reproduction context, and expected behavior. The Cha…
Linked Issues check
Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check
Check skipped because no linked issues were found for this pull request.
Full details: Title check
Explanation
The title names the main change: a branch's own pull request now shows past more than a hundred same-named fork pull requests. The raw summary and objectives confirm the change adds a retry through the open-only lookup when the all-states page is full with no open match. The title follows the conventional commit style that the repository template asks for.
Full details: Description check
Explanation
The description follows the template. It has Problem, Change, Scope and approval, and Verification sections. The Problem section gives the bug, the reproduction context, and expected behavior. The Change section explains the retry through findOpenPr. The Scope section covers why no prior issue exists, and it names the limitation for closed or merged pull requests. The Verification section gives the focused test command, the before and after results, and the unchecked items. The template's comment asks authors to say what was not checked, and the description does this. The description does not link a triaged issue or maintainer approval. It explains why the fix qualifies as a very small, focused fix of an obvious bug, which the template allows. The template's comment says the author should end with the model and harness that did the work, and the description does this with a generated-with line.
Finishing Touches
Generate unit tests (beta)
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
This review was completed with usage-based billing: files reviewed beyond your plan's included limits are billed at $0.25/file. View usage-based billing.
verified unchanged head a459d6bda2f517337548c46da71b03d7cb05207d on linux, using the dev web client, playwright with google chrome, real github api responses, and real codex gpt-6.1-sol turns. no mocks, fixtures, or demo data.
reproduced on github/main (cec8d73a1f): a real checkout of micro-jumbo/DefinitelyTyped on master has open draft pr DefinitelyTyped/DefinitelyTyped#73307, but t3 shows no pr and offers "Create PR". github's first 100 all-state master results exclude #73307; its open-only results contain it (11 results total).
on this pr's exact head, the same checkout and thread show #73307 and its title. the websocket branch status changes from pr: null to the correct open draft pr. opening it loads its summary and code file list. real codex turns completed on both servers and returned the same branch and sha.
nearby behavior passed: a different real fork's first-page pr #75865 appears; creating an unpublished branch through the ref picker clears that association and offers "Create PR"; switching back restores #75865.
blacksmith: all 126 git manager tests passed. vp run check:changed HEAD^ passed format, lint, knip, graphql, typechecks and 128 tests. supplied the parent ref after fetching shallow history because the worker initially lacked a main merge base. existing ci has no failing or pending checks. no code changes or pushes were needed.
native desktop, ios/android, remote relay/tunnel connections, other source-control hosts, and non-codex providers were not exercised. closed or merged prs hidden beyond the first 100 rows remain outside this fix's stated scope. no external pr creation, push, merge, or review mutations were exercised.
Thank you, Maria, for testing this against real GitHub. That is the one thing the description listed as not checked, since our run used a stub API with fake data. Your run reproduced the bug on main with a real repository: the first 100 all-state master results left out open draft #73307, so T3 showed no PR and offered "Create PR". On this head the same checkout showed #73307 and its title, and branch status went from pr: null to that PR.
Your nearby checks cover the paths this change must leave alone. A fork whose PR is on the first page still shows it (#75865). A new unpublished branch clears the association and offers "Create PR", and switching back restores it.
Noted that desktop, mobile, remote connections, other hosts and other providers were outside this pass. As you say, closed or merged PRs past the first 100 rows stay out of scope, as the description states.
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
size:XS0-9 changed lines (additions + deletions).vouch:unvouchedPR author is not yet trusted in the VOUCHED list.
2 participants
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.
github-actions
Bot
added
vouch:unvouched
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
Problem
A branch loses its pull request in T3 when more than 100 newer pull requests from other forks use the same branch name. The git actions control shows no pull request, so its pull request actions are gone too. Busy repositories hit this with common names: a fork's
mainormaster, or GitHub's web-edit defaultpatch-1. For example,DefinitelyTyped/DefinitelyTypedhas about 15,000 pull requests from heads namedmaster, andMicrosoftDocs/azure-docshas about 12,000 frompatch-1. A pull request open for a few days in such a repository falls out of the newest 100.Branch status looks the pull request up by the bare branch name: one page of the 100 newest pull requests in any state, then GitManager keeps the rows whose head repository is the branch's own. #13200 chose this so that "same-named branches on other forks can no longer crowd out the real match". Once more than 100 newer same-named pull requests exist, that page holds only other forks' rows and nothing matches. Open pull requests are far fewer (tens at most on those repositories), so the open-only lookup that Create PR already uses still finds it.
Change
In
GitManager.findLatestPrForHeadContext, when an all-states page comes back full and holds no open match, look the branch up once more with the existing open-only lookup (findOpenPr) and use its result. A page that is not full, or one with an open match, makes the same single request as today. The provider, its query and the head probe are unchanged.Scope and approval
This is a very small, focused fix for an obvious bug, so it comes without a prior issue. It makes the lookup #13200 designed hold past its first page, using a lookup that already exists, with no new setting, query or UI. It covers every host through the same code; GitHub and Azure DevOps use the 100-row probe.
Left as is: a branch whose own pull request is closed or merged, with more than 100 newer same-named pull requests, still shows none. Finding it would need paging the bare branch name across all states, which can mean thousands of rows.
Verification
Test, a new case in
apps/server/src/git/GitManager.test.ts: a fork branch whose all-states page holds 100 closed pull requests from other forks, and whose open lookup returns its own pull request.vp test run apps/server/src/git/GitManager.test.ts -t "finds a fork branch's open PR past a full page of other forks' PRs"onmain: fails withexpected null to match object { number: 1, state: 'open' }. With the fix: passes, and the listings asked for["all", "open"].vp run check:changedpasses.Web, against a local stub GitHub Enterprise API on loopback serving the fake repository
acme/web: 129 merged or closed pull requests from forksfork-2tofork-130on headpatch-1, created after the repository's own open pull request #1 on the same head. The project is a local checkout on branchpatch-1.Before (
main): the git actions control onpatch-1offers "Create PR" and shows no pull request. The stub's log has one lookup forpatch-1, all states, first 100, which returns #130 to #31.After (this branch): the same view shows "#1: Update the getting started g…" and the pull request chip below the composer. The log has the same all-states lookup, then an open-only lookup that returns #1.
Not checked:
Generated with Claude Opus 5.5 in T3 Code Nightly