`checkGitHubForPrBranch` associates branches with stale closed PRs via their tracked upstream (e.g. branches tracking `origin/dev`)

[tmastny]

Info:

• Extension version: 0.136.0
• VSCode Version: 1.116.0 (Universal)
• OS: macOS 26.3.1
• Repository Clone Configuration: single repository
• GitHub Product: GitHub.com

Summary

ReviewManager.checkGitHubForPrBranch looks up PRs by branch.upstream.name and writes the result to branch.<name>.github-pr-owner-number with no state === 'OPEN' guard. For any local branch that tracks a shared upstream like origin/dev, this resolves to whatever closed PR ever used head=dev on that repo, and the stale mapping persists permanently (because the write only fires when no metadata exists).

Symptoms: the GitHub Pull Requests panel logs This PR is no longer valid / Unable to resolve PR #..., the PR view won't open for the branch, and git config branch.<name>.github-pr-owner-number points to an unrelated closed PR.

Steps to Reproduce:

Prerequisite: a repository with at least one CLOSED PR whose headRefName is a commonly-tracked base branch name (dev, main, etc.). In my case the offending PR was closed without merge in October 2024.

1. Create a new local branch tracking the base ref:

   git checkout -b my-feature origin/dev
   

   (Equivalent triggers: git worktree add <dir> -b my-feature origin/dev, or git branch --track my-feature origin/dev.) This sets branch.my-feature.merge = refs/heads/dev and branch.my-feature.remote = origin.
2. Open the repo in VS Code with the GitHub Pull Requests extension enabled.
3. Within a few seconds (on activation or the 5-min poll), checkGitHubForPrBranch fires.
4. Inspect config: git config --get branch.my-feature.github-pr-owner-number — it references an old closed PR whose headRefName was dev.

Subsequently, even after pushing my-feature with -u (which corrects branch.my-feature.merge to refs/heads/my-feature), the stale PR mapping persists because the write path is gated on "no metadata exists". The PR view remains broken until the config entry is manually unset.

Expected

No mapping should be written. A local branch tracking origin/dev has no PR reachable via its upstream's head ref name — the branch's own (future) remote ref would be my-feature, not dev.

Actual

Output log shows:

[Review+0] Found matching pull request metadata for current branch my-feature. Repo: owner/repo PR: <OLD_CLOSED_PR_NUMBER>
[Review+0] Resolving pull request
[Review+0] This PR is no longer valid
[Review+0] Unable to resolve PR #<OLD_CLOSED_PR_NUMBER>

The stale mapping also spreads to any branch created from origin/dev before being pushed with its own name. In my workspace 17 distinct branches ended up with this mapping over a few months of normal worktree-based development.

Root cause

All permalinks pinned to 6596ede (current main).

1. ReviewManager.checkGitHubForPrBranch calls getUpstreamUrlAndName to extract upstreamBranchName.
2. getUpstreamUrlAndName returns branch.upstream.name when upstream is populated, or falls back to branch.<name>.merge minus the refs/heads/ prefix. For a branch tracking origin/dev, both paths yield upstreamBranchName = "dev".
3. checkGitHubForPrBranch passes that to getMatchingPullRequestMetadataFromGitHub, which dispatches to doGetMatchingPullRequestMetadataFromGitHub → GitHubRepository.getPullRequestForBranch("dev", headOwner).
4. The GraphQL query PullRequestForHead runs with headRefName: "dev" — no state filter.
5. Client-side filter at githubRepository.ts#L752:

   const mostRecentOrOpenPr = prs.find(pr => pr.state.toLowerCase() === 'open') ?? prs[0];

   If no matching open PR exists, returns prs[0] — any closed PR that ever used head=dev can match.
6. PullRequestGitHelper.associateBranchWithPullRequest writes the stale mapping to git config.

The semantic mistake: upstreamBranchName is treated as "this branch's name on the remote", but for a branch tracking a base branch (a very common pattern — e.g. git worktree add -b X origin/dev), it's actually the base branch's name on the remote, not the feature branch's future name.

Proposed fix

Option 1: in checkGitHubForPrBranch (or inside getMatchingPullRequestMetadataFromGitHub), skip the GitHub lookup when upstreamBranchName !== branch.name. A branch whose upstream ref name differs from its local name is tracking a base branch, not its own remote counterpart, and has no PR discoverable via that name.

Option 2: add a state === 'OPEN' guard to getPullRequestForBranch's client-side filter. This prevents closed-PR pollution even if the "different name" check is missed. It won't help in the rare case that an open PR happens to exist on the shared upstream.

Either fix should also address the same pattern in FolderRepositoryManager.associateLocalBranchesWithPRsOnFirstActivation.

Related

• Closed PRs get associated with new branches of the same name #6711 covers the "same branch name reused after a PR closes" variant of the stale-metadata family. This issue is a distinct, broader trigger — branches that track a base branch rather than reusing a head ref name.
• error git config --local branch.main.github-pr-owner-number #6134 first flagged github-pr-owner-number config-level misbehavior.