Pull request diff often times out

[Lacoste]

Over the past year or so the performance of the Bitbucket Cloud pull request screen has noticeably degraded.  I have received numerous reports from developers in my organization of the pull request diff panel timing out before the diff is loaded.  Sometimes a manual refresh can fix this issue, but at other times multiple attempts to load the pull request screen will fail.  The error that appears on screen says,

Something went wrong
The diff has timed out. For more information on diff limits or managing pull request size, refer to Limits for viewing content and diffs. If this issue persists, contact support.atlassian.com.

The problem is that these diffs are not large; some are as small as a few changed line in a handful of files or less.  The timeout issue appears to be unrelated to the size of the diff itself, although it may be related to the size of the repo in question (more on this below).  With the JS console open, I see this error appear when the diff times out:

[Error] Failed to load resource: the server responded with a status of 555 () (<repo_name>:779b5391850b
bf5555f8fbdd, line 0)

So far, we have only observed this issue in one repo, which tracks work on our largest and oldest project.  While the disk size of this repo isn't TOO large (581.9MB), it has a long history spanning about 47K commits.  (Our "short" commit IDs are 10 characters.)  It may be that the problem is not the size of the diffs themselves, but the underlying repo history.

However, the repo is what it is, and we would not want to consider truncating our history just to resolve a technical issue on Bitbucket's side.  The pull request interface's performance under these conditions is unacceptable, and fueling discussion of leaving Bitbucket for GitHub.  If there is anything Atlassian can do to improve performance, I would rather stay than migrate and undertake the headache that goes with that.  But we can't stay if it continues to behave this way.

[Norbert C]

Hi @Lacoste 

Thank you for contacting Atlassian Support, my name is Norbert and I'm a Bitbucket Cloud Support Engineer, it's nice to meet with you!

As you have this issue on a specific repository, I would suggest to run a Git GC on the repository on the server side as it will clear the dangling commits on the repository, plus it also repacks the repository, thus the repository will have a better performance.

As it's not suggested to share confidential information (for example WorkspaceID + repository name) via the Community Portal, I'm going to open a ticket on our support portal and one of our colleague will reach out to you.

Best Regards,
Norbert
Atlassian Bitbucket Cloud Support

[EmanuelPoremba]

Hello,

we have the exact same issue in our organization. And of course, a git gc didn't solve the issue. We have to reload the PR page 2-10 times until bitbucket manages to show the PR.

[Norbert C]

Hi Emanuel,

Please excuse me for the late reply. Do you still have this behavior? We've improved the performance on complex diffs, thus you shouldn't have this issue anymore: https://bitbucket.org/blog/improving-performance-on-complex-diffs

Please let me know.

Best Regards,
Norbert
Atlassian Bitbucket Cloud Support

[EmanuelPoremba]

Norbert,

yes, this has solved the issue with the cost of the loss of a merge preview. We can now only see the changes of the branch itself (merge with merge-base), which is to be expected by your changes.

[Norbert C]

Hi Emanuel,

Thank you for your reply. I'm glad to hear it's resolved.

Best Regards,
Norbert
Atlassian Bitbucket Cloud Support

[Matt]

The loss of merge preview from this change has been a problem for us, it would be better if we had the option between 2-way and 3-way diff (for smaller repos the performance benefit of 2-way diff is not useful, and so the advantage of 3-way diff is much better). I also don't think the rebase solution mentioned here works in all scenarios (e.g. when repeatedly merging a feature branch into a development branch, where the development branch also contains commits from other WIP features).  @Norbert C is there any good way around this issue, or is it possible to re-enable 3-way diffs for us repo owners who would prefer it?

Thanks
Matt

[Norbert C]

Hi Matt

Let me begin by saying I am really sad to hear that our latest changes to the diffs are upsetting you. Please let me clarify to you that while we were proudly the sole source code management tool in the industry who supported the preview-merge diff, it was very significantly impacting the performance we were able to deliver to our customers. The complexity to calculate the preview merge diffs is the very reason why other SCM providers made the choice never to even introduce them their customers.

While the preview-merge diff showed the changes made to the destination branch in the diff, if the feature branch was not synced with the latest from the target branch then the feature branch code was not tested with the latest target branch code.

You mentioned that you don't think the rebase solution might work for you. To test whether it's working or not, can I ask you to fork the repository and rebase the forked repository? 

Unfortunately currently it's not possible to change the type of the preview diff, we have a feature request for this as you can see in the link below:

• BCLOUD-21964 - Preview-merge diff type on demand

Our development team will give a first-hand update on that ticket if there's any progress made so I would suggest keeping a watch and vote for it.

Do note however that there's no ETA on enhancement request, and all enhancements are implemented with this policy in mind: Implementation of New Features Policy

Please let us know how it goes by trying the rebase in the forked repository?

Best Regards,

Norbert

Atlassian Bitbucket Cloud Support