Pull Requests in Bitbucket Data Center do not get updated with the latest commit after NFS changes
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
The Pull Requests in Bitbucket Data Center sometimes do not get updated with the latest commits. This happens intermittently and only affects some Pull Requests. The issue may occur when the source or target branch of the PR gets updated with a new commit. This should trigger Bitbucket to execute a rescoping process - however, if the problem occurs, the PR still doesn't show the expected latest commit, sometimes even after a long time (eg. several hours). In the same time, on another PR, if the problem does not occur, the new commit is reflected almost instantly.
Diagnosis
If a user declines and re-creates the Pull Request, the latest commit is instantly shown in the new PR. However, being forced to do this frequently results in a poor user experience.
Occasionally, the affected PR may update itself after some time.
Cause
One of the common causes of this issue is using NFS with incorrect mount options. On each server hosting the Bitbucket node, check the NFS mount options in /etc/fstab. The documentation recommends the following mount options for NFS:
1
rw,nfsvers=3,lookupcache=pos,noatime,intr,rsize=32768,wsize=32768,_netdevDifferent mount options - especially the missing option: lookupcache=pos - may cause these intermittent rescoping issues.
Using this option allows Bitbucket nodes to quickly detect new directory entries created by the other nodes, while still providing some of the performance benefits of caching.
Without this option, lookupcache=all is assumed as a default option. In this configuration, if Bitbucket checks a file, and the file doesn’t exist, the negative lookup result is cached. Later, another node may create this file, but the first node will not see it, because it already has the negative lookup result in the cache. As a result, when rescoping an updated Pull Request, the node may not see the new files and conclude that rescoping for this PR is not needed. Rescoping for this PR will be skipped, and the PR will continue to show the stale commit, until the PR gets re-created, or another commit results with a successful rescoping.
Solution
Edit /etc/fstab on each node hosting Bitbucket and make sure the NFS is mounted with the recommended options (especially lookupcache=pos).
Next, on each node (one after another), stop Bitbucket, re-mount NFS with the new options, then start Bitbucket once again.
Once all the nodes use NFS mounted with the correct options, this issue should be resolved.
Was this helpful?