# \[Bug\]: Bitbucket API calls fail with 429s after startup because we hammer it too hard · Issue \#23885 · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/issues/23885)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

State: completed

Priority: 0

## Description

[Discussion and activity](https://git.cafe/pingdotgg/t3code/issues/23885)

---

### Before submitting

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

### Area

apps/desktop

### Steps to reproduce

## How to reproduce this

Start T3 Code and open a project with many threads on their own branches, with the Bitbucket source control provider enabled. In the console log, you will see 429 rate limits. In the desktop interface, Bitbucket functions will fail for some time (often hours), until Bitbucket allows your API key to make more requests.

## Cause

At startup `ThreadPullRequestServiceV2` sweeps every thread and looks up each branch's pull request, up to 32 at once, then repeats every minute. For a Bitbucket project each lookup is a `listPullRequests` call.

GitHub requests go through a shared request policy: a concurrency cap, a quota reserve, and a host-wide pause after a 429 (`SourceControlRateLimit`). `BitbucketApi` sends every request directly, with no concurrency limit and no shared pause. So after the first 429, every queued lookup still goes out and gets its own 429, which keeps the hourly quota exhausted.

I have a focused fix ready (Bitbucket client only, with tests) and can open a PR if this direction works for you.


### Expected behavior

After a 429, Bitbucket background reads should back off host-wide, as GitHub's do. The startup sweep shouldn't send dozens of Bitbucket requests at once, and a user's own actions should still get through while the background sync waits.

### Actual behavior

With the Bitbucket integration configured, the server regularly gets HTTP 429 from Bitbucket Cloud. It's worst right after startup: the server log fills with one warning per thread branch, all failing the same way.

Once the quota is spent, Bitbucket features that need a live API call (pull request status, opening a PR) fail too until the limit resets (which can be a very very long time).


### Impact

Major degradation or frequent failure

### Version or commit

Version 0.1.1 (fe27e8e3dc12)

### Environment

macOS 27.0.1 (26A434), T3 Code Version 0.1.1 (fe27e8e3dc12)

### Logs or stack traces

```shell
WARN: thread branch pull request lookup failed
  cause: SourceControlProviderError: Source control provider bitbucket failed in listChangeRequests: Failed to list change requests.
      at findLatestPrForHeadContext
      at lookupBranchPullRequest
      at branchPullRequest
      at ThreadPullRequestServiceV2.synchronize
    [cause]: BitbucketResponseError: Bitbucket API failed in listPullRequests: Bitbucket returned HTTP 429.
```

### Screenshots, recordings, or supporting files

_No response_

### Workaround

I have not found a workaround. I have a focused fix ready (Bitbucket client only, with tests) and can open a PR if this direction works for you.