Unable to see other users' branches when creating Pull Requests

Branch count has not yet reached 1500

Then it isn't the size guidance. That leaves the index cause on that page, which fits your banner anyway.

Timing is what will make or break the ticket. It only happens occasionally for you, so note the exact times you see the message and raise it while it's happening if you can. Otherwise they'll be looking at a repo that's behaving fine.

Hi @Rachna Bhavsar 

The next time it occurs - can you check the network tab in your browser console and look for a traceID/SentryError on the HTTP request and share that code with us?

If you're unable to - please let me know as I'll need to raise a ticket. Please let me know your timezone so I may raise it with the appropriate team.

Cheers!

- Ben (Bitbucket Cloud Support)

TraceId:fe5e85ad04d34a87a56ae6ba67f99806

Another issue has been observed with Bitbucket.

There are two separate workspaces. Let's say Workspace 1 is mine and Workspace 2 belongs to another developer. I have access to some branches in the other workspace as well.

However, when I try to create a pull request within my own workspace and my own repository for a specific branch, I notice an issue with the reviewer list. Bitbucket is displaying a user who is not a member of my repository (they belong to the other workspace/repository), while another user who is currently a member of my repository is not available for selection as a reviewer.

Could you help explain why Bitbucket is showing a user from a different workspace/repository as a reviewer while not listing the current user who should have access to this repository?

Our setup:

• I have my own Bitbucket workspace and repository.
• User2 has his own workspace and repository and is the primary maintainer of this project.
• My normal workflow is to create a Pull Request from my branch/repository to User2 's branch/repository.

Issue:

• While creating a Pull Request, I can no longer see User2's repository/branches for selection.
• I can successfully fetch User2's branches using Git (git fetch), and the remote branches are visible locally.
• The issue appears to be limited to the Bitbucket Cloud Pull Request UI.

• We have also intermittently seen the following message: "The repository is currently being indexed. Please try again later."

Additionally, we have noticed that a user who left our organization several years ago still appears in the Pull Request interface, which makes us suspect there may be a repository metadata or indexing issue.

Questions:

1. Could the repository indexing issue be preventing User2's repository/branches from appearing in the Pull Request UI?
2. Is there a way to refresh or rebuild the repository metadata/indexes?
3. Does this require Bitbucket Cloud Support to perform repository maintenance (such as garbage collection)?

The reviewer list is a separate bug. Reviewer search only stays scoped to your workspace when the repository is private, on a public repo it searches every Bitbucket account, which is how someone from User2's workspace, and maybe your old colleague, surfaces as a suggestion. Check Repository settings, Repository details, Access level, and confirm this repository is private is ticked.

For the member who's missing, workspace membership alone doesn't earn a reviewer slot. They need Read on this specific repository, granted separately under the repo's own Settings, Repository permissions.

On the indexing questions: the KB you and Ben are already using names indexing problems as one of three causes, there's no self-serve rebuild on Cloud, and GC is Support-only. With your trace IDs posted, that's in his hands now.

Thanks for the clarification — that explains the reviewer list, makes sense.

I'll check the repository's Access level under Repository settings and confirm it's set to private, and will also review Repository permissions to grant explicit Read access to the missing member. Will follow up if either of those doesn't resolve as expected.

For the indexing issue itself, understood that it's with your engineer now given the trace IDs already posted — please let us know once GC/reindexing has been run, or if you need anything further from our side in the meantime. This is still blocking us from raising PRs against [User2's repo], so any update on timeline would help.

@Ben @gab any update on our issue?

No update from my side, I've no visibility into the ticket Ben raised. Ben, is there an issue key Rachna can track this against?

Separate from the banner, something to rule out. You're raising PRs from your repo in your workspace into User2's in his. Atlassian scheduled cross-workspace fork relationships to be automatically broken on 1 July 2026, and that page says you "will not be able to create a cross-workspace PR from the fork to the parent if the relationship is broken": Fork a repository

If yours was a fork of his, an authenticated GET /2.0/repositories/{workspace}/{repo_slug} on your own repo settles it. A parent still naming User2's repo means the link is intact and this isn't it. A null tells you less, it reads the same for a repo that was never a fork.

I wouldn't lean on it. The page is still future tense so I can't confirm it ran, and your 27 July post had the branches missing only occasionally, which isn't what a one-off severing looks like.

This might be related to the fact that my repository was originally forked from User2's repository when we started development. It could be contributing to the issue, although I'm not certain.

It does. I said a missing parent proved little, but yours had one, so run the check. A parent still naming User2's repo means the link is intact and it's all Ben's. Nothing there and it's gone, assuming that was the Fork button and not a clone you pushed up. It still doesn't prove what's emptying the picker. The occasional branches and the banner from 27 July stay his regardless, a severed link doesn't come and go.

One date says how it went. When did you last raise a PR into his repo successfully? Anything after 1 July rules out the sweep and leaves the manual route. Detach fork landed in March, in the fork's own settings under Repository details, Manage repository, and Atlassian calls it "a one-time action that cannot be undone". It's your workspace, so a short list.

Ask User2 to move you from read to write instead, push your branch to his repo and raise the PR there. No fork in the path.