Self-hosted Bitbucket (Server/Data Center) remotes are treated as Bitbucket Cloud → useless api.bitbucket.org traffic; request Bitbucket Server support #14591

Activity

1. juliusmarminge commented on Oct 1, 2026

   

   juliusmarminge

   on Oct 1, 2026

   Last edited by juliusmarminge

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks for the detailed traces. I confirmed this on current main. It's a real bug, and not a regression in 0.0.43-nightly.20260928.

   Any remote whose hostname has a bitbucket DNS label gets classified as Bitbucket. That includes Data Center hosts like bitbucket.example.com, which are labeled "Bitbucket Self-Hosted" and stored as provider: "bitbucket" (isBitbucketHost and detectSourceControlProviderFromRemoteUrl in packages/shared/src/sourceControl.ts). The test "matches self-hosted providers by complete DNS labels" locks that in. Hosts without that label stay unknown and never reach this client.

   The HTTP client ignores the remote's host. BitbucketApi always calls one process-wide Cloud root, which is https://api.bitbucket.org/2.0 unless T3CODE_BITBUCKET_API_BASE_URL overrides it, and it uses Cloud paths (/user, /repositories/{workspace}/{repo}/pullrequests, and so on). A Data Center clone URL like https://bitbucket.example.com/scm/<project>/<repo>.git still matches. The locator keeps only the last two path segments, so the request goes to Cloud as <project>/<repo>. Any credentials from Settings or T3CODE_BITBUCKET_* are attached to that request, and with no credentials it's still sent.

   T3CODE_BITBUCKET_API_BASE_URL doesn't add Server support. It only changes the origin for the same Cloud client. Data Center serves /rest/api/1.0/projects/{KEY}/repos/{slug}/..., which this code never builds, so the 302 you saw from /2.0/repositories/... is expected. Pointing that variable at a real Data Center origin would also send your configured Cloud token there, since that's the origin the client trusts.

   That explains the traffic in your traces. PullRequestSyncReactor re-reads linked pull requests (open, unsettled links on the one-minute sweep), and each Bitbucket summary fans out through PullRequestService.persistedRead / PullRequestReadCache into several Cloud calls. Branch status and pull-request creation use the same client whenever the checkout is classified as bitbucket.

   This isn't the same as the GitLab self-hosted case. GitLab.com and self-managed GitLab speak one API, and glab is scoped to the remote's host. Bitbucket Cloud and Bitbucket Server/Data Center are different APIs, and nothing here implements REST 1.0, instance HTTP access tokens, or a per-host base URL. Data Center pull-request URLs (/projects/{KEY}/repos/{slug}/pull-requests/{n}) aren't parsed either.

   What should change for this bug: don't call the Cloud API for any host other than bitbucket.org unless a Cloud base URL was explicitly configured. Those checkouts should be marked unsupported for pull-request sync and the pull-request browser. That stops the api.bitbucket.org traffic without needing a new setting. The "Bitbucket Self-Hosted" label also promises more than the client can currently do.

   Bitbucket Server / Data Center support (URL shapes, REST 1.0, instance tokens) would be a separate feature, already requested in Discussion #10837. There's also no per-project switch to turn off PR sync today, but one isn't needed to stop this traffic.

   The unkillable backend doesn't look like a T3 Code bug. A process that survives taskkill /F, sits at 0% CPU in DelayExecution, and is left with one thread stuck in the kernel matches the endpoint-security hang you suspected, and SQLite still accepting reads fits that too. Stopping the outbound Cloud calls is the mitigation here. A desktop watchdog couldn't recover a process the OS itself can't kill.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 1, 2026
3. juliusmarminge commented on Oct 22, 2026

   

   juliusmarminge

   on Oct 22, 2026 – with GitCafe Production

   Member

   More actions

   The unintended Bitbucket Cloud traffic is already covered by open PR #22029, which explicitly fixes this issue and includes regression tests and before/after runtime evidence. No duplicate fix PR is needed. I have not independently reproduced the reported backend freeze.

   Full Server/Data Center support, a per-project sync toggle, and frozen-backend recovery remain feature requests for Ideas discussion. The existing PR identifies discussion #10837 as the Server/Data Center support tracker. Leaving this issue open for the dispatcher to handle discussion conversion.
4. pingdotgg

   locked and limited conversation to collaborators on Oct 22, 2026
5. juliusmarminge

   converted this issue into a discussion #23325 on Oct 22, 2026