pingdotgg / pingdotgg/t3code

[Bug]: Thread shows the base branch's PR when the branch tracks a non-default base

Open
#8,209 0 comments 0 reactions 0 assignees View on GitHub

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
  1. Use a repository whose GitHub default branch is main but which integrates through a second branch: feature branches are cut from dev, and dev reaches main through release PRs. gh pr list --head dev --state all therefore returns a list of merged dev -> main PRs.
  2. git checkout -b feature/x origin/dev, so branch.feature/x.merge is refs/heads/dev. Plain git and T3's own base-branch flows both leave a branch tracking the ref it was cut from.
  3. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.