Getting an HTTP 400 error when trying to zap the cache of a virtual Helm repo in Jfrog Artifactory via API

I'm having a problem with the cache of a virtual Helm repository (containing only a local repo) on a self-hosted JFrog Artifactory (version 7.49.8). I was trying to zap the cache of the entire repo via the API https://jfrog.com/help/r/jfrog-rest-apis/zap-cache.

However, I keep getting status 400 errors, no matter whether I try the virtual or repo or the local repo (as the error message suggests):

curl -H "X-Jfrog-Art-Api: $ADMIN_API_KEY" \
  http://artifactory.my-company.com/artifactory/api/zap/my-virtual-helm-repo

{
    "errors": [
        {
            "status": 400,
            "message": "Repository 'my-virtual-helm-repo' is not a local repository"
        }
    ]
}

Alright, so I tried zapping the local repo that's included in the virtual repo (even though the UI doesn't offer zapping of local repos):

curl -H "X-Jfrog-Art-Api: $ADMIN_API_KEY" \
  http://artifactory.my-company.com/artifactory/api/zap/my-included-local-helm-repo

{
    "errors": [
        {
            "status": 400,
            "message": "Got a zap request on a non-local-cache node 'my-included-local-helm-repo:'."
        }
    ]
}

I'm able to Zap Cache the virtual repo via the Artifactory UI. What's the trick to get the REST call to work?

Let's break this answer into two parts:

Part 1 - What does Zap cache serve?

Zapping a cache refers to forcing the Retrieval Cache Period and Missed Retrieval Cache Period to time out. You can also zap an entire repository cache. This information is derived from JFrog documentation. In other words, the Zap Cache function resets the MCRP for the whole cached repository, ensuring that fresh metadata is sent to the client after the Zap.Zap Cache Link

Users who need accurate and up-to-date metadata should lower the setting, potentially disabling it by setting it to "0". This action would result in slower pulls because Artifactory would frequently serve fresh metadata. However, this ensures that the most accurate data is always used. If users prioritize performance, they should increase this setting. Nevertheless, doing so means that Artifactory will use its cache more often than not, compromising accuracy. Refer to "How does remote repository work" to gain a better understanding.

Part 2 - Understanding the reason for failure

After comprehending the term and its significance, it's important to mention that zapping cache on virtual repository differs from zapping cache from remote repository ( The API endpoint is different)

For triggering a zap cache API on remote repository it is exactly as you mentioned above. interesting read on how remote repositories work

For triggering a zap cache on a virtual repository:

curl -H "X-Jfrog-Art-Api: $ADMIN_API_KEY" 'http://artifactory.my-company.com/artifactory/api/artifactactions/zapVirtual' -H 'Content-Type: application/json' -H 'Accept: application/json, text/plain' --data-raw '{"repoKey":"npm-virtual","path":""}' 

{"info":"The caches of 'def-npm' have been successfully zapped."}

To resolve this issue, you can try troubleshooting by checking if there are any errors in the API request URL or payload, verifying that you have sufficient permissions to perform the action, and ensuring that there are no temporary issues with Jfrog Artifactory's servers or network.