Unable to see other users' branches when creating Pull Requests

[Rachna Bhavsar]

I am experiencing an issue in our Bitbucket Cloud repository. Occasionally, when creating a Pull Request, I cannot see other users' branches in the branch dropdown, even though the branches exist.

At the same time, Bitbucket displays the message: "The repository is currently being indexed. Please try again later."

Could this indexing issue be causing the missing branches? Is there a way to refresh or resolve the repository indexing?

[Gabriela - LeanZero]

Hi @Rachna Bhavsar, yes, those two go together. Atlassian's KB for commits and branches not rendering lists internal database and indexing problems as one of the causes, and the remedy there isn't self-serve. Bitbucket Cloud Support run garbage collection on the repo, which rebuilds the internal databases and indexes. No reindex button on your side.

Check the repo's branch and tag count before you raise it. That same page puts the guidance at under 1,500 branches and tags combined, and says Bitbucket Cloud can't guarantee reliable performance above that.

Issues viewing repository commits and branches

[Rachna Bhavsar]

Branch count has not yet reached 1500

[Gabriela - LeanZero]

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.

[Ben]

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)

[Rachna Bhavsar]

TraceId:fe5e85ad04d34a87a56ae6ba67f99806

traceid:306177d0698e45a587454f4b98c21f71

[Rachna Bhavsar]

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?

[Rachna Bhavsar]

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)?

[Gabriela - LeanZero]

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.

[Rachna Bhavsar]

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.