Occasionally when copying/deploying multiple RPMs to a yum repo, it seems as if the repodata files generated by Artifactory get into an out of sync state where the repomd.xml files end up referencing a <chksum>-primary.xml.gz file that doesn't exist. (There are multiple copies of these in the repodata directory, none of which are the ones referenced by repomd.xml) This results in clients using the repo throwing errors such as:
Running yum clean all on the client seems to have no effect so it appears as if it's a server side problem.
The only apparent fix is to manually remove the "repodata" directory from Artifactory and force it to recreate the metadata (which is a little more difficult than would be expected since using the calculate yum repository metadata API endpoint generally gives a 409 error "Unable to perform immediate YUM metadata calculation on a repository with auto-async calculation enabled"
I've seen this issue now happen a couple of times Artifactory Professional 5.9.1 rev 50901900 (but also previously saw it on 5.8.x as well). Prior to 5.8 I never saw this issue at all.
Is there some other workaround for this issue to get the repodata in a "sane" state again? We use some of our yum repos for public software deployment so it is not a good experience for them to get errors while downloading software from our repos.
This kinda seems like the reverse case of https://www.jfrog.com/jira/browse/RTFACT-7494