Sign up
View stargazers13Sign up

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

opened24d agobyBBerkayClik

Summary

Repos hosted on a self-hosted Bitbucket Server / Data Center instance (e.g. https://bitbucket.example.com/scm/proj/repo.git) are detected as kind: "bitbucket" ("Bitbucket Self-Hosted") because isBitbucketHost() matches any host. But BitbucketApi only speaks the Bitbucket Cloud API (DEFAULT_API_BASE_URL = "https://api.bitbucket.org/2.0", /2.0/repositories/{workspace}/{repo}/...). As a result, the PR sync reactor keeps querying api.bitbucket.org for a repository that lives on a completely different server.

Observed

  • T3 Code Nightly 0.0.43-nightly.20260928, Electron desktop app.
  • Remote: https://bitbucket.example.com/scm/<project>/<repo>.git (Bitbucket Data Center).
  • Across rotated server.trace.ndjson logs: spans to https://api.bitbucket.org (2,165 Interrupted, 136 Failure, 896 Success), from PullRequestSyncReactor.syncGroup / PullRequestReadCache / PullRequestService.persistedRead.
  • Pointing T3CODE_BITBUCKET_API_BASE_URL at the self-hosted server does not help: Bitbucket Server exposes /rest/api/1.0/projects/{KEY}/repos/{slug}/..., while /2.0/repositories/... on that host returns 302 (login redirect).

Possibly related: backend freeze → " is reconnecting" forever

Twice in one day, the backend froze shortly after some of these api.bitbucket.org requests were Interrupted:

  • Last log spans: PullRequestSyncReactor spans (Interrupted) → then silence. The UI showed " is reconnecting" indefinitely.
  • The frozen backend: 0% CPU; the port still accepts connections; main thread in wait reason DelayExecution.
  • After the app window was closed, the backend process could not be killed (Stop-Process -Force / taskkill /F fail; 1 thread left, stuck in kernel). It keeps its port (3773, 3774...) until reboot, and each restart picks the next port.
  • The machine runs corporate endpoint security (EDR + web/DLP filter + App Volumes), so the unkillable process is likely a kernel filter driver hang, not T3 Code itself. The trigger appears to be the high volume of cancelled outbound HTTPS requests to api.bitbucket.org. Orphaned, hung git.exe processes (git config --null --type=path http.* spawned by Git Credential Manager) were also present.
  • Not ruled out: SQLite locking (tested: read and BEGIN IMMEDIATE on state.sqlite succeed instantly while frozen).
  • Workaround: point T3CODE_BITBUCKET_API_BASE_URL at 127.0.0.1:9 (requests fail locally in ~80 ms, so there is no outbound traffic).

Requests

  1. Don't call api.bitbucket.org for non-bitbucket.org hosts. For Bitbucket Self-Hosted, either skip PR sync or require explicit configuration.
  2. Bitbucket Server / Data Center support (REST API 1.0, HTTP access token auth, per-host base URL), similar to how GitLab self-hosted is handled.
  3. Add a setting to disable PR sync per project.
  4. (Nice to have) Make sure aborted PR-sync HTTP requests can't wedge the backend, and that the desktop app detects a frozen backend and restarts it instead of showing "reconnecting" forever.
JJulius Marminge24d ago

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.

JJulius Marminge3d ago

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.

This conversation has been locked.