Show all PRs associated with a worktree #8895

Activity

1. Rohan-Singla

   added

   enhancementNew feature or requestNew feature or request

   on Oct 26, 2026
2. github-actions commented on Oct 26, 2026

   

   github-actionsBot

   on Oct 26, 2026 – with GitHub Actions

   Contributor

   More actions

   Triage: show every PR linked to a worktree

   Summary. This is a feature request, not a bug. When several PRs belong to one worktree, the desktop sidebar shows only one of them. The reporter wants all of them listed, each with its status and link. From the code, this matches the current design: a workspace has one "currently linked" PR, and the sweep chooses it by the branch the workspace tracks upstream. The host already keeps a full list of every PR a workspace has been linked to, but the desktop app does not read it.

   Affected code

   Data model

   • packages/host-service/src/db/schema.ts:246: workspaces.pullRequestId is a single nullable pointer. It is the one PR the sidebar shows.
   • packages/host-service/src/db/schema.ts:374-397: workspace_pull_requests is an append-only history table. Its docstring says workspaces.pullRequestId "stays the single 'currently linked' pointer the sidebar shows… a workspace that opens a PR per branch accumulates one row each."

   How the current PR is chosen

   • packages/host-service/src/runtime/pull-requests/pull-requests.ts:972-1049: for each workspace, the refresh builds one key from its upstream owner, repo and branch. It looks up one PR for that key and overwrites pullRequestId (:1027). It also records the link in history (:1034).
   • packages/host-service/src/runtime/pull-requests/utils/github-query/github-query.ts:145-163: normalizePullRequestCandidates uses .find(...) and returns only the first PR whose head matches. Other PRs on the same head are dropped.
   • Legacy path: apps/desktop/src/lib/trpc/routers/workspaces/utils/github/pr-resolution.ts:254 takes sortPRCandidates(...)[0], so it also returns one PR.

   Read side

   • packages/host-service/src/trpc/router/pull-requests/pull-requests.ts:18-36: getByWorkspaces returns only the current PR. The desktop sidebar uses it, in DashboardSidebar/hooks/useDashboardSidebarData/useDashboardSidebarData.ts and v2-workspaces/hooks/useAccessibleV2Workspaces/useAccessibleV2Workspaces.ts.
   • packages/host-service/src/trpc/router/pull-requests/pull-requests.ts:42-54: historyByWorkspaces already exists. It returns every linked PR, current one first (pull-requests.ts:445-512), with state, draft flag, review decision, checks status and URL. Only mobile reads it (apps/mobile/.../useWorkspacePullRequest.ts:57, apps/mobile/lib/voice/tools/data.ts:372). Nothing in apps/desktop calls it.

   Why only one PR shows

   1. Different branches over time. If the worktree switched branches and opened a PR on each, every PR is saved in workspace_pull_requests. The pointer moves to the newest match, and the desktop UI only renders the pointer.
   2. Several PRs on the same branch. For example, PRs from one branch to different base branches. The head lookup keeps only the first match, so the extra PRs are never linked or recorded in history.
   3. PRs on other branches from the same ticket. If the user opened them from another worktree or by hand, nothing links them to this workspace. Showing them would need a new way to associate them, such as a task or ticket id.

   How to reproduce

   1. In one v2 workspace, push branch a and open a PR.
   2. Check out branch b in the same worktree, push it and open a second PR.
   3. Wait for the refresh sweep. The sidebar shows only the PR for b. Calling pullRequests.historyByWorkspaces with that workspace id returns both.

   A bun:test sketch could follow the existing tests near packages/host-service/src/runtime/pull-requests/pull-requests.test.ts:1962: link two PRs to "ws", then assert that getPullRequestsByWorkspaces returns one and getPullRequestHistoryByWorkspaces returns two.

   For case 2, a unit test of normalizePullRequestCandidates with two candidates on the same head would show the second one being dropped.

   Possible fix

   • Most of the work: the desktop UI. Query pullRequests.historyByWorkspaces beside getByWorkspaces. Keep the current PR as the main chip, and list the other PRs (perhaps open ones only, or all with state badges) in a hover card or expandable row. The response already has every field the request mentions.
   • Same-branch case. Change the head lookup to return every matching candidate, not just the first. Then record each one in workspace_pull_requests, while one still becomes the pullRequestId pointer.
   • Other branches or worktrees for the same ticket. This needs a product decision on how PRs are associated, so it is out of scope for a first pass.
   • These are new reads only. They do not change any procedure that released builds call, but packages/trpc/AGENTS.md still applies if anyone changes a procedure's response shape.
3. moizghumann commented on Oct 27, 2026

   

   moizghumann

   on Oct 27, 2026

   More actions

   CI, Deploy Preview, and Sandbox are all blocked by GitHub Actions approval requirements for external contributors. Could a maintainer approve the workflow runs so the checks can execute?
4. moizghumann commented on Oct 27, 2026

   

   moizghumann

   on Oct 27, 2026

   More actions

   @Rohan-Singla
5. rohanblockcap commented on Oct 27, 2026

   

   rohanblockcap

   on Oct 27, 2026

   More actions

   looks good to me Moiz not a maintainer to review tho . thanks