How Priority Resolution Works
Priority Resolution in Artifactory determines how metadata is merged from repositories in a virtual repository. When enabled, Priority Resolution ensures that metadata is merged only from repositories marked with this setting. If the required package is not found in those repositories, Artifactory will then merge metadata from repositories that do not have the Priority Resolution enabled.
More information regarding priority resolution can be found in our documentation under Advanced Settings for Local Repositories and Advanced Settings for Remote Repositories.
In some cases, where a package with different versions is present in two (or more) repositories under a Virtual repository and one of these repositories has Priority Resolution enabled, it is possible that an attempt to resolve a specific package version will fail with a 404.
However, the abovementioned behavior is dependent on how the client sends the metadata request to Artifactory.
Example Scenarios
Let's assume that under a single Virtual, we have two NPM local repositories, which both have the package “my-package”, each with a different version. When the NPM client sends the metadata request and mentions only the package name (Even though the NPM install command explicitly requests for a specific version, e.g. “npm i my-package@1.0.0”), what is happening here is that Artifactory will return the metadata merged only from the repositories with the “Priority Resolution” enabled since the NPM client did not specify the required version Artifactory does not know that the merged metadata is missing that specific version, and will not try to look at the Metadata from the other repositories. The NPM client will search in the returned Metadata for the specific version, but since it is not included, the NPM client will throw a 404 error.
NPM request to get the metadata specifying only the package name (my-package), without the version:
2024-12-31T11:57:27.042Z|66623f5427493b28|172.16.1.6|admin|GET|/api/npm/npm-virtual/my-package|200|-1|1427|15|npm/9.9.3 node/v18.16.0 darwin arm64 workspaces/false
This behavior will be similar to ANY client that does not specify the package VERSION in the metadata request.
The PIP client is requesting the Metadata:
2024-12-31T10:11:30.421Z|e6700855c5fac4e8|172.16.1.6|admin|GET|/api/pypi/pypi-virtual/simple/cffi/|200|-1|508449|1022|pip/24.0 {"ci":null,"cpu":"arm64","distro":{"name":"macOS","version":"14.7"},"implementation":{"name":"CPython","version":"3.12.2"},"installer":{"name":"pip","version":"24.0"},"openssl_version":"OpenSSL 3.3.2 3 Sep 2024","python":"3.12.2","rustc_version":"1.83.0","setuptools_version":"69.5.1","system":{"name":"Darwin","release":"23.6.0"}}
The Maven client is requesting the maven-metadata.xml.
2024-12-31T11:15:063.739Z|cb4e41d67c4a2511|172.16.1.6|admin|GET|/maven-libs-snapshot-virtual/org/jfrog/test/multi/3.8-SNAPSHOT/maven-metadata.xml|200|-1|329|207|Apache-Maven/3.9.9 (Java 17.0.8.1; Mac OS X 14.6.1)
On the other hand, if the Docker client sends the first request for the metadata including the specific tag requested, then Artifactory still will merge first the metadata only from the repositories which has the Priority Resolution” enabled. However, in that case, Artifactory knows that the merged metadata is missing the required tag (Since the Docker client sent the tag), and will then search for that tag on the other repositories and will be able to resolve it.
Docker requests to get the Metadata including the tag (specificTag).
2024-12-31T11:23:03.542Z|3a2be266b46c1bd9|172.16.1.6|admin|GET|/api/docker/docker-virtual/v2/my-image/manifests/specificTag|200|-1|134|12|docker/26.1.5 go/go1.22.5 git-commit/411e817ddf710ff8e08fa193da80cb78af708191 kernel/6.6.51-0-virt os/linux arch/arm64 UpstreamClient(Docker-Client/27.2.1-rd \(darwin\))
Resolution
In cases when the same package with different versions is present in multiple repositories under a single Virtual, the “Priority Resolution” should be similar between all of these repositories, either enabled or disabled.