fix(bitbucket): scan repos as they're discovered and fix dead My-PR endpoint

[sunnywty]

Summary

• Cache the repository list and start fetching pull requests for a repo as soon as it's discovered, instead of waiting for the entire workspace's repo list to finish paginating first. This overlaps repo-list pagination with PR fetching so results start streaming in sooner.
• Fix "Search My Open Pull Requests", which was consistently returning a 404. Bitbucket has removed the workspace-wide "list PRs for a user" endpoint it depended on. It now reuses the same per-repo scan as "Search All Open Pull Requests", filtered server-side to the current user's PRs via the q query param.
• Add an optional, per-command "Max Repository Age (days)" preference (default 0 = no limit) that skips repositories not updated within N days.

Why the age-limit preference matters

I have 100+ repositories in my workspace, and most of them are stale (no recent activity, no open PRs). Both search commands have to make one API call per repository (Bitbucket has no workspace-wide "list PRs" endpoint), so a full scan across all of them sometimes triggers Bitbucket's rate limiting, causing failed/incomplete results. Letting a workspace skip long-dormant repos entirely cuts both the number of API calls and the chance of getting rate-limited, while defaulting to 0 (scan everything) keeps existing behavior unchanged for anyone who doesn't set it.

Test plan

• npm run build / ray lint pass with no errors
• Manually tested in ray develop: both "Search All Open Pull Requests" and "Search My Open Pull Requests" load results correctly, including with the age preference set and unset
• Reviewer: verify with your own Bitbucket workspace/credentials since this depends on live API behavior

🤖 Generated with Claude Code

[raycastbot]

Thank you for your contribution! 🎉

🔔 @Lp-Francois @esarmstrong @itsrifat @skuio @arpitdalal @LitoMore @AaronMoat @0xdhrv @Siuhinnn you might want to have a look.

You can use this guide to learn how to check out the Pull Request locally in order to test it.

📋 Quick checkout commands

BRANCH="bitbucket-limit-stale-repo-scans"
FORK_URL="https://github.com/sunnywty/raycast_extensions.git"
EXTENSION_NAME="bitbucket"
REPO_NAME="raycast_extensions"

git clone -n --depth=1 --filter=tree:0 -b $BRANCH $FORK_URL
cd $REPO_NAME
git sparse-checkout set --no-cone "extensions/$EXTENSION_NAME"
git checkout
cd "extensions/$EXTENSION_NAME"
npm install && npm run dev

We're currently experiencing a high volume of incoming requests. As a result, the initial review may take up to 15 business days.

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge. No new issue was found in the latest changes.

Findings

1.  cacheConfig also wraps repository search, whose getRepositoriesLazy fetcher calls Bitbucket directly. Setting shouldRetryOnError to false removes SWR's retry there too. A temporary network, rate-limit, or server error can now leave that command failed with no refresh action. Scope this setting to the pull-request scans, or add retry behavior to repository search. ▶

Fix with agent prompt

### Issue 1
extensions/bitbucket/src/helpers/cache.ts:undefined-40
`cacheConfig` also wraps repository search, whose `getRepositoriesLazy` fetcher calls Bitbucket directly. Setting `shouldRetryOnError` to `false` removes SWR's retry there too. A temporary network, rate-limit, or server error can now leave that command failed with no refresh action. Scope this setting to the pull-request scans, or add retry behavior to repository search.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

Bitbucket pull-request searches now scan repositories through a shared, cached worker queue, so results can appear while the workspace is still being read. “Search My Open Pull Requests” now uses per-repository filtering instead of the removed workspace-wide endpoint, and both commands can skip old repositories with a per-command age limit.

• Repository pages feed up to ten pull-request workers as soon as they arrive.
• Repository lists are cached for ten minutes and requests retry rate-limit and server errors.
• “Search My Open Pull Requests” filters by the current user’s author or reviewer UUID.
• Both scan commands add “Max Repository Age (Days)”, defaulting to 0 for no limit.

_{Reviews (10) · Last reviewed commit: "fix(bitbucket): scope shouldRetryOnError..."}

[pernielsentikaer]

Hi @Lp-Francois 👋

We're reviewing PR #31240 and I'd like your take as the extension author before we move ahead — do you consider any of this breaking for existing users?

The main change is Search My Open Pull Requests: Bitbucket removed the workspace-wide .../pullrequests/{user} endpoint it relied on (that was the 404), so it now scans each repository and filters per repo with q=author.uuid="…". Same command name and UI, but results now depend on every repo scan succeeding, and it honours the new repo-age setting.

It also adds a per-command Max Repository Age (Days) preference (default 0 = unchanged) and a 10-minute repository-list cache, and the PR cache keys changed, so the first run after upgrading re-scans.

Command names/IDs, existing preferences, and the author/contributors metadata are unchanged. Does that look safe to you as a non-breaking fix, or is there behaviour here (e.g. what the old "my PRs" endpoint actually returned) that would break existing setups? 🙂

---

I’ll convert this PR into a draft after submitting this review. Please press Ready for review when it’s ready and we’ll have a look 😊

[sunnywty]

Thanks for the review, @pernielsentikaer! I'm the one who made these changes (not the original extension author), so let me answer directly:

Not breaking, and here's why: "Search My Open Pull Requests" is currently returning a 404 for every user today, on the version already in the store. It calls /workspaces/{workspace}/pullrequests/{selected_user}, which Bitbucket has removed (the code even had a comment linking to the Atlassian community thread about this). So there's no currently-working behavior being changed here — this PR fixes a command that's already broken for everyone.

Good catch prompting a real fix: your question made me go verify the old endpoint's exact scope instead of assuming. That endpoint historically returned PRs the user authored or was a requested reviewer on (dashboard-style), but my per-repo replacement was only filtering on author.uuid, which would have silently narrowed results (missing PRs awaiting the user's review). I just pushed a fix broadening the query to (author.uuid OR reviewers.uuid) to match the original scope.

"Search All Open Pull Requests" behavior is unchanged by default: the new "Max Repository Age (Days)" preference defaults to 0 (no limit — same full scan as before), so nothing changes unless a user opts in.

Cache key changes are internal/ephemeral only: it's an in-memory + local-disk performance cache, not user data. Worst case after upgrading is one slightly slower first search while it repopulates — nothing is lost.

Command names/IDs and existing preferences are all unchanged, so this should be safe to review as a non-breaking fix + opt-in perf improvement. Happy to answer anything else.

[pernielsentikaer]

I’d like to hear from @Lp-Francois, the original author. I’ll give him two days to check in before going further 🙂

[Lp-Francois]

This is now N+1 API calls, could we hit rate limits because of this?

[Lp-Francois]

this can throw if preferences are invalid somehow

We should probably put a queue.close in a finally and wrap the rest in try{}. Wdyt?

[sunnywty]

Good catch — this can indeed throw (bad maxRepoAgeDays, a failed repo-list API call, etc.) before every repo is queued, which would leave the worker pool awaiting queue.next() forever. Just pushed a fix: wrapped feedRepos's body in try/finally so queue.close() always runs regardless of where it throws (commit 6e1296f).

[sunnywty]

Found and fixed a real bug while testing this: on a handful of very actively-developed repos in a large workspace, "Search My Open Pull Requests" was intermittently rendering duplicate PR rows (React duplicate-key warnings) and, in one case, causing the process to run out of memory.

Root cause: Bitbucket's page param on pullrequests.list is an offset, not a stable cursor. On a repo where new PRs are opened continuously during the scan, that shifts already-seen PRs into the next page's offset window, re-returning them — and in the worst case (PR creation rate matching or exceeding scan throughput) !data.next can effectively never terminate the loop.

Fix (commit e48a0bb): de-dupe by PR id within a repo's own pagination, track how many new PRs each page actually contributes, and stop as soon as a page contributes nothing new — instead of relying solely on !data.next. Also added a 40-page hard cap as a backstop. Verified via temporary diagnostic logging that this was in fact happening on our end (not just a rendering artifact) before landing the fix.

[pernielsentikaer]

Do you want to check it again @Lp-Francois