Bitbucket Smart Mirror Metadata or Content hashes show as 0000000000000000000000000000000000000000
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
When checking the metadata or Content hash of mirrored repositories using the REST API endpoints `rest/mirroring/latest/repo-hashes` or `rest/mirroring/latest/repo-hashes/metadata`, the metadata hash appears as `0000000000000000000000000000000000000000`.
Environment
7.21.x,8.x
Diagnosis
Try checking the metadata or Content hash using the API endpoints `rest/mirroring/latest/repo-hashes` or `rest/mirroring/latest/repo-hashes/metadata` which displays the metadata hash or the Content hash as 0000000000000000000000000000000000000000.
Cause
When an upstream instance is first upgraded to a mirror farm-capable version((6.7+), an "empty" content hash is generated for each repository, which appears as `0000000000000000000000000000000000000000`.
So if the repository contents or metadata (such as the repository name or project name) hasn't changed since the upgrade to Bitbucket 6.7+, the metadata or content hash might never have been calculated for these repositories and would show as `0000000000000000000000000000000000000000`.
This explains why the metadata and the Content hash might be set to `0000000000000000000000000000000000000000` on both the primary and the mirror.
Solution
The metadata and content hash being set to `0000000000000000000000000000000000000000` is not a concern, as it is handled internally by the Bitbucket farm vet repair process. When the farm vet encounters a repository with a metadata or content hash of `0000000000000000000000000000000000000000`, it considers that repository up to date.
If you want to reset the content or metadata hash from empty, you should make some changes to the repository name to trigger a metadata hash generation, and push some changes to the repository to trigger the content hash generation. This will cause the mirror to automatically sync the updated content hash from the primary.
Was this helpful?