[Bug]: Thread shows the base branch's PR when the branch tracks a non-default base
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 23k
- Forks
- 5.9k
- Avg merge
- 11h 14m
- Merged PRs (30d)
- 357
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Use a repository whose GitHub default branch is
mainbut which integrates through a second branch: feature branches are cut fromdev, anddevreachesmainthrough release PRs.gh pr list --head dev --state alltherefore returns a list of mergeddev -> mainPRs. git checkout -b feature/x origin/dev, sobranch.feature/x.mergeisrefs/heads/dev. Plain git and T3's own base-branch flows both leave a branch tracking the ref it was cut from.- Open a thread on that checkout and leave the branch unpushed, so it has no change request of its own.
Expected behavior
No PR badge. The branch has no pull request.
Actual behavior
The thread row and the composer footer show the newest merged dev -> main release PR (#49 in my case), which has nothing to do with the thread. Every thread on that checkout shows the same number, and it moves to whatever the next release PR is.
prLookupCache in apps/server/src/git/GitManager.ts derives the head selector from the upstream ref, so the lookup asks for --head dev. The guard right below it only suppresses that when the upstream is the repository default branch (main or master), so a non-default base falls through, and findLatestPrForHeadContext returns the most recently updated PR when none is open. Because that PR is merged, the client then keeps it across checkouts (retainTerminalOnBranchMismatch in ThreadStatusIndicators.tsx), and a merged PR also settles the thread.
Impact
Major degradation or frequent failure
Version or commit
0.0.34-nightly.20260825.1183, also present on main @ e67074f
Environment
macOS (Darwin 25.2.0), desktop nightly, GitHub through gh
Workaround
git push -u origin HEAD so the upstream carries the branch's own name, or git branch --unset-upstream.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in apps/server/src/git/GitManager.ts at prLookupCache and findLatestPrForHeadContext, then inspect retainTerminalOnBranchMismatch in ThreadStatusIndicators.tsx. Reproduce with a branch tracking non-default dev that has no own pull request; done means no unrelated merged PR badge appears and the thread is not settled or retained because of it.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, github, typescript
- Domain
- devtools, full-stack
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 75/100