We have been actively monitoring this issue and we are happy to see that the issue has been impacting our customers at a much lower pace over the last several months. We attribute this improved trajectory to numerous architectural improvements we were able to put in place over the last while. The issue is still occassionally reported but it is unclear now whether it still shares the same root cause as its original counterpart. As a result, we have decided to close this original issue and start tracking the symptoms under a new BCLOUD ticket. This will allow us to more easily track the influx of customer reports and focus on the latest possible root cause of the issue. If you experience these symptoms please report them under the new BCLOUD ticket.

https://jira.atlassian.com/browse/BCLOUD-22728

How can it be classified as MAJOR, yet in the long term backlog, and opened since 2019? This is surreal.
Happened to me yesterday.

• Branches section showed the newly pushed branch, indicating the branch was 1 commit ahead of the main branch
• Commits section was not showing the commit at all even when filtering by that new branch
• PR didn't work as it thought the new branch was identical.

Pushing another commit "unblocked" that mess.

I experienced this same issue yesterday. Several branches claimed to show no commits and I couldn't open a PR with a new branch even though Bitbucket Pipelines kicked off as expected. The only way to fix this was to push another, unrelated branch. Related support ticket: BBS-184795.

I have experience this too: BBS-182875

From speaking to colleagues, others have experienced this too in the (not so distant) past, but didn't raise a ticket for it. Deleting the branch via Bitbucket and pushing up my local branch was a work around that worked for us.

We have found the race condition that was responsible for this issue. While we couldn't fully eliminate it in the short-term we were able to significantly reduce its probability. We've been monitoring this issue for the past one week and we see the customers are indeed subjected to it much less. As a result I will be reducing the priority of this ticket.

We have implemented the changes in such a way that we can easily fine-tune the parameters of the fix based on the customer impact. Please let us know here if you continue to be impacted by this issue and in the meantime please refer to the Workaround section above to unblock your workflow.

For a long-term solution we have recently kicked off a project to fix the issue fully so we will keep this ticket in the `In Progress` state, but this is a larger project and will take us some time to complete.

Yana

I have raised a support ticket (ticket Id : BBS-173995) with the required details.

a6115d423bfd

Please raise a support ticket with us at https://support.atlassian.com/contact/#/

and specify affected repository URL and a branch name and we will be happy to investigate it for you. 

Thank you and apologies for the inconvenience. 

Still we are unable to see the missing commits and the workaround (refreshing the repository) didn't worked.

Same issue here. Opened a support ticket and was directed here, apparently this is a HIGHEST priority ticket (despite being open for 2 years apparently).

Four different staff affected in the last few months, across at least four different repositories.

Workaround is to create a new branch locally (based on the original branch which shows as empty) and push that to Bitbucket. As soon as it's been pushed, the commits appear on that branch and on the original broken/empty branch (even though you didn't push to it).

example: 

# 1) Push original branch to Bitbucket
$ git push origin feature/my-feature
Enumerating objects: 13, done.
Counting objects: 100% (13/13), done.
Delta compression using up to 8 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 635 bytes | 635.00 KiB/s, done.
Total 7 (delta 4), reused 0 (delta 0)
remote: 
remote: Create pull request for feature/my-feature
remote:   https://bitbucket.org/workspace/repository/pull-requests/new?source=feature/my-feature&t=1
remote: 
To bitbucket.org:workspace/repository.git
 * [new branch]        feature/my-feature -> feature/my-feature

# 2) Check Bitbucket and feature/my-feature has NO history (This is the BUG)

# 3) Clone current branch and push to Bitbucket
$ git checkout -b feature/my-feature-2
$ git push origin feature/my-feature-2
Enumerating objects: 13, done.
Counting objects: 100% (13/13), done.
Delta compression using up to 8 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 635 bytes | 635.00 KiB/s, done.
Total 7 (delta 4), reused 0 (delta 0)
remote: 
remote: Create pull request for feature/my-feature-2
remote:   https://bitbucket.org/workspace/repository/pull-requests/new?source=feature/my-feature-2&t=1
remote: 
To bitbucket.org:workspace/repository.git
 * [new branch]        feature/my-feature-2 -> feature/my-feature-2

# 4) Check Bitbucket and both feature/my-feature-2 AND the original feature/my-feature branch are working fine now

# 5) You can delete feature/my-feature-2 now

 The problem is when a coworker pushes their code but doesn't realise it failed (they saw a success message in their terminal they have no way of knowing this), and then you try to branch from that only to find it isn't available. And if they're not working that day, you're stuck. In one case I was able to track down their commit hash, navigate directly to the commit (which did exist despite not being in any of the branches), create a tag through the UI, create a new branch from the tag, and then pick up from there.

Edit: Looks like this ticket was only assigned a priority a month ago, so it does appear that it's being worked on 

We seem to get this every time when doing a merge from a development branch into our staging branch