You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Bitbucket sends 5 requests per pull request on every sync #27578
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
Configure Bitbucket Cloud credentials and link several Bitbucket pull requests to threads.
Leave the server running.
Count the Bitbucket requests under each PullRequestSyncReactor.sweep in server.trace.ndjson.
Expected behavior
A sync reads the pull requests it needs in a few requests. Repository permission is read once per repository, not once per pull request, and diffstat and conflicts are reread only when the head commit changes. One GET /repositories/{workspace}/{repo}/pullrequests returns each pull request's state, updated_on and head commit, which is enough to tell which ones changed.
Actual behavior
Bitbucket's getChangeRequest sends 5 requests for every pull request: the pull request, diffstat, conflicts, statuses and repository permission. GitHub batches pull request reads into one GraphQL request; Bitbucket reads each pull request separately.
With 12 linked pull requests and the one-minute retry from #17799, that is about 3,600 requests an hour. Bitbucket allows 1,000 an hour for most endpoints, so the host stays paused (#23885) and every Bitbucket feature fails.
Impact
Major degradation or frequent failure
Version or commit
0.1.6-nightly.20261030.3917
Environment
Linux x64, desktop AppImage, Bitbucket Cloud
Logs or stack traces
PullRequestProviderError: bitbucket failed in getChangeRequest: bitbucket requests to bitbucket.org are paused until the rate limit resets.
Workaround
Unlink Bitbucket pull requests you don't need, especially on settled threads.
More evidence from a t3 triage session, this time on stable builds with a single linked pull request (desktop 0.1.6 and 0.1.7, macOS arm64, Bitbucket Cloud).
A single pull request can reach 429s when its reads keep failing. Between 09:48 and 11:28 UTC on 2026-11-05, the retained traces show 161 Bitbucket GET attempts involving one repository and one pull request, about 97 an hour. Of those, 47 returned 404, 8 returned 429, 105 were interrupted before a status was recorded, and 1 was a 403 from /2.0/user. PullRequestSyncReactor.syncGroup ran about once a minute during this period. The counts may include reads from an open pull request panel as well as background sync.
The 5 requests per pull request also holds on 0.1.7. After a working credential was saved at about 11:27 UTC, each cycle from 11:28 to 11:58 UTC made the same 5 requests at 5-minute intervals, all returning 200: pull request, diffstat, conflicts, statuses, and repository permission. No 429s were recorded through 01:20 UTC on 2026-11-06.
I can't tell which credential, if any, was active during the failures. If those requests were unauthenticated, a lower limit for anonymous requests could explain 429s at this volume.
Posted by Claude Code (claude-opus-5-5) via t3 triage.
Activity
pyhrus commentedon Nov 6, 2026
More evidence from a
t3 triagesession, this time on stable builds with a single linked pull request (desktop 0.1.6 and 0.1.7, macOS arm64, Bitbucket Cloud).A single pull request can reach 429s when its reads keep failing. Between 09:48 and 11:28 UTC on 2026-11-05, the retained traces show 161 Bitbucket GET attempts involving one repository and one pull request, about 97 an hour. Of those, 47 returned 404, 8 returned 429, 105 were interrupted before a status was recorded, and 1 was a 403 from
/2.0/user.PullRequestSyncReactor.syncGroupran about once a minute during this period. The counts may include reads from an open pull request panel as well as background sync.The 5 requests per pull request also holds on 0.1.7. After a working credential was saved at about 11:27 UTC, each cycle from 11:28 to 11:58 UTC made the same 5 requests at 5-minute intervals, all returning 200: pull request, diffstat, conflicts, statuses, and repository permission. No 429s were recorded through 01:20 UTC on 2026-11-06.
I can't tell which credential, if any, was active during the failures. If those requests were unauthenticated, a lower limit for anonymous requests could explain 429s at this volume.
Posted by Claude Code (claude-opus-5-5) via
t3 triage.