Sign up
View stargazersSign up

[Bug]: "All servers" PR list assigns a shared repository to the primary environment even when that environment can't read the host#21365

opened23d agobyMmahirozdin

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

Pull requests page (multi-environment / "All servers" filter)

Steps to reproduce

  1. Connect a desktop client to two environments:
    • A: the desktop's local environment (primary). Bitbucket is not configured under Settings → Source Control.
    • B: a remote environment. Bitbucket is configured with a valid Atlassian email and API token, and its Source Control status shows authenticated.
  2. Register the same Bitbucket repository (e.g. workspace/repo) as a project in both environments.
  3. Open the Pull requests page and set the server filter to All servers and the host filter to All.
  4. Then set the server filter to environment B only.

Expected behavior

"All servers" should be a superset of every single-server view. A repository that environment B can read should still be listed when A can't. Either it falls back to an environment that can read the host, or it is read from every environment that has it and the results are deduplicated.

Actual behavior

  • With All servers, the Bitbucket PRs are missing. The Bitbucket host and project options are shown as disabled ("Unavailable") with the tooltip "Bitbucket rejected the configured credentials. Check them in Settings → Source Control." That message comes from environment A's 401.
  • With only environment B selected, the same PRs show up correctly.

The server traces confirm this: in "All servers" mode, environment B's pullRequests.list request makes no Bitbucket calls at all (no getViewer, no /pullrequests listing). Only GitHub repositories are read. Calling pullRequests.list on B directly with {state:"open"} returns the Bitbucket provider as configured: true and lists the PRs.

Likely cause

In the PR page client (_chat.pull-requests chunk, 0.1.0 build), "All servers" mode deduplicates projects by repository key across environments and sends each environment a projectIds filter. The assignment helper (minified pc(projects, environmentOrder, primaryEnvironmentId)) always prefers the primary environment (Ke[0]) for a repository that exists in more than one environment. It does not check whether that environment's provider for the host is configured or readable, and it does not fall back after that environment reports the host as unusable (configured: false / unauthenticated). The repository is therefore never requested from environment B.

Impact

Medium. PRs silently disappear from the default "All servers" view. The UI suggests a credentials problem even though a connected server is correctly authenticated, which sends users to reconfigure credentials on a machine that never needed them.

Version or commit

T3 Code 0.1.0 (desktop "T3 Code (Beta)" on macOS, remote server 0.1.0 on Linux)

Environment

  • Client: macOS 27.0.1 desktop app (local environment = primary)
  • Remote: Linux x64 headless server, connected over Tailscale/relay
  • Provider: Bitbucket Cloud (API token auth); GitHub repos in the same list work fine

Logs or stack traces

Environment A (local), repeated during "All servers" listing:

1GET https://api.bitbucket.org/2.0/user -> 401

Environment B (remote), same refresh: ws.rpc.pullRequests.list → only GitHubApi.graphql children; no Bitbucket spans. Environment B, direct pullRequests.list {state:"open", host:"bitbucket.org"} → providers[bitbucket].configured = true, 3 open PRs, errors: [].

Workaround

Select the remote server explicitly in the server filter, or configure the same Bitbucket credentials on the primary (local) environment too.

JJulius Marminge23d ago

Note

Grok responding on behalf of Julius.

Confirmed on main. Listing each shared repository from only one server is deliberate since #6039, so the same pull requests don't show up twice. But the choice of server ignores whether that server can read the host.

assignProjectsToEnvironments in pullRequestProjectAssignment.logic.ts gives a repository held by several servers to the preferred server, which is the first queried environment. It only looks at repository identity and server order, never at host configuration or auth. So when that server's host read fails, the repository is never requested from a server that could read it, and the page shows the first server's credential error.

Scoping the list to the remote server, or setting up the same Bitbucket credentials on the local environment, works around it for now.

Possible directions:

  • Leave out servers whose host summary reports it as not configured when assigning a shared repository, and fall back to the next server that holds it.
  • Or re-request repositories whose assigned server reported the host as unusable from the other servers that hold them.

Related but separate: #16068 (one viewer per host) and #20728.