Merged PR is dropped once its remote branch is deleted, un-settling the thread

[LouisHaftmann]

What happened

From the user:

I work remotely over Tailscale through the desktop app and sometimes after updating the desktop app many of the previously settled threads just come back. I checked the web app of the backend t3 server I'm using remotely over the desktop app and it also shows the threads as unsettled.

Follow-up answers: every affected thread had settled because its PR merged, never by clicking Settle. The threads stay wrong for a long time, and opening one does not fix it.

Diagnosis

The settle lifecycle in the database is intact. Across 715,331 orchestration events there are 38 thread.unsettled events total, and for all 774 threads carrying settled_override = 'settled' the projection agrees with the last settle-related event in the log. Nothing un-settled anything.

The threads that come back are the ones with no override, which stay settled only while the server reports a merged or closed PR. They lose that PR permanently, and the reason is branch cleanup after merge.

1. The repo has "Automatically delete head branches" enabled, so merging deletes the head branch on GitHub. Once anything prunes the stale remote-tracking ref locally, refs/remotes/*/<branch> is gone and @{u} no longer resolves. T3 does not prune (its background fetch is git fetch --quiet <remote>, apps/server/src/vcs/GitVcsDriverCore.ts:2909), but VS Code auto-fetch, git fetch --prune, and gh pr merge --delete-branch all do.

2. isUnpublishedBranch (apps/server/src/git/GitManager.ts:1277) decides whether a branch was ever pushed using exactly that ref: the repo tracks some remote, but no refs/remotes/*/<branch> exists. A merged and cleaned-up branch is indistinguishable from a branch that was never pushed.

3. GitManager.ts:974 then short-circuits the PR lookup and returns { latest: null }. gh is never called, so the merged PR that gh pr list --head <branch> --state all still returns is never seen.

4. effectiveSettled (packages/client-runtime/src/state/threadSettled.ts:300) receives changeRequest = null, changeRequestAutoSettles returns false, and the thread falls through to the inactivity rule. With the default sidebarAutoSettleAfterDays = 3 it sits in Active until three days of silence pass.

Because this is derived from server data, the web app and the desktop app agree, which is what the user saw.

The tie to updating the desktop app is indirect. No orchestration event fires when the PR vanishes, so a connected client keeps rendering its last good thread list. A restart refetches and the whole backlog appears at once, and an app update is a restart.

On this machine 24 of the 35 threads that depend on PR state have no remote-tracking ref and no upstream, so they are un-settled right now. The 11 healthy ones are recent merges whose stale ref has not been pruned yet.

Steps to reproduce

1. Use a repo with "Automatically delete head branches" enabled.
2. Start a thread on its own worktree branch, push it, open a PR.
3. Merge the PR. The thread auto-settles and shows the merged PR badge.
4. Prune the deleted remote branch locally, for example git fetch --prune in that checkout. VS Code auto-fetch with git.pruneOnFetch does this on its own.
5. Wait out PR_LOOKUP_CACHE_TTL (2 minutes), then load the thread list in a freshly started client.

Expected: the thread stays settled and keeps its merged PR badge.

Actual: the PR badge is gone, the thread is back in Active, and it stays there until the 3 day inactivity rule catches it. Clicking into the thread does not restore it.

Version

0.0.34-nightly.20260820.1141 (diagnosed against main at f708f63)

Environment

Linux x64, Node v26.6.0. Server runs as a systemd user service (npm exec t3@nightly server --host <tailscale-ip>), desktop app connects to it remotely over Tailscale. GitHub CLI as the source control provider.

Evidence

Branch whose PR merged and whose head branch GitHub deleted:

 $ git for-each-ref --count=1 refs/remotes/*/<branch>
 (empty) -> isUnpublishedBranch: true
 $ git for-each-ref --count=1 refs/remotes | wc -l
 86 -> repo tracks remotes
 $ git rev-parse --abbrev-ref --symbolic-full-name @{u}
 fatal -> details.upstreamRef: null
 $ gh pr list --head <branch> --state all --json number,state
 [{"number":<n>,"state":"MERGED"}] -> the PR is still there

Scope on this machine (threads not deleted, not archived, no settle override,
activity in the last 4 days):

 35 threads depend on PR state
 24 have no remote-tracking ref and no upstream -> PR lookup short-circuits

Settle lifecycle is clean, so nothing wrote this state:

 sqlite> select count(*) from orchestration_events; 715331
 sqlite> select count(*) from orchestration_events
 where event_type = 'thread.unsettled'; 38
 774 threads with settled_override='settled', all matching the event log

Unrelated but visible in the same window, cold-start PR lookups failing with
an empty in-memory fallback map (GitManager.ts:1003), 75s after service start:

 08:03:32 WARN: PR lookup failed; keeping last known PR state.
 operation: lookupStatusPr
 branch: <redacted>
 providerOperation: listChangeRequests
 providerCommand: gh
 errorDetail: GitHub CLI command failed.

Related issues

#4752 (closed) and #4831 (closed) are the same family, a thread losing a merged PR, but neither covers this trigger. #4752 is the local checkout switching back to the default branch, which is suppressed by the isDefaultBranch rule at GitManager.ts:1067. #4831 is projection_threads.branch going stale after the agent renames the branch. Here the worktree stays on its own branch and the stored branch is correct, and the suppression comes from isUnpublishedBranch. #4970, #5514 and #7517 all point at the same weak thread-to-PR binding by branch name.

Fix applied or workaround

Nothing was written on the machine. The database was read only.

Workaround: click Settle on the affected threads once. effectiveSettled checks the explicit override at threadSettled.ts:328 before it looks at the PR, so the override survives this. Auto-settle on merge stays broken for future merges.

Filed by

Claude Opus 5 via t3 triage (Claude Code)

[t3dotgg]

Thanks for the report. We believe this is fixed by PR #6216.

The server now checks the branch's remote and merge configuration before treating a missing remote-tracking ref as an unpublished branch. A tracked branch should keep its merged PR badge and settled state after the remote branch is deleted.

I'm closing this as fixed as part of an automated pass on all open issues. If this still happens in a build that includes PR #6216, please reply with the branch's remote and merge configuration and the PR URL, and we can reopen it.