Proxy repository taking precedence over Hosted when retrieving packages

Sonatype Nexus Repository
,
1

Hello,

I’m facing a very peculiar issue when fetching a package from a Nexus Group repository.
For context, here’s the current structure of our repositories:

“Group” npm repository
├── “Proxy” npm repository
└── “Hosted” npm repository

We’re currently working with a company that is publishing packages both to the public npm registry, and to our “Hosted” npm repository to which they have access.

The published packages have the exact same naming and version convention, however the ones being published to our “Hosted” npm repository by them, are actually different.

The issue that we’re facing is that whenever a developer tries to install the package from the Group repository which they have been instructed to use, Nexus is prioritizing fetching the package from the Proxy repository, instead of the Hosted even if it already exists in the Hosted.

We have ruled out every possible issue with cache by disabling temporarily the Proxy repository, followed by a Cache Clean and Index Rebuild on it → doing this forces Nexus to fetch from hosted, but once Proxy repository is enabled, fetching packages from group goes to Proxy once again, rather than Hosted.

The second way we have confirmed is was by using the Nexus assets API:

https://our.nexus.server/nexus/service/rest/v1/search/assets?repository=group-repository&q=*package-name*

Running the above command we can see in the JSON that the Group repository has a pointer to the package ONLY on the Hosted (after the package is deleted on the Proxy), but when a new request for that package is done to the Group, we rerun the query and begin seeing a new pointer to the package on the Proxy repository, like this:

{
	"items": [
		{
			"downloadUrl": "https://our.nexus.server/nexus/repository/proxy-repository/package-folder/-/package-name-0.0.15.tgz",
			"path": "package-name/-/package-name-0.0.15.tgz",
			"id": "id-of-package-from-proxy",
			"repository": "proxy-repository",
			"format": "npm",
			"checksum": {
				"sha1": "sha-of-proxy-package"
			},
			"contentType": "application/gzip",
			"lastModified": "2024-01-29T06:21:26.851+00:00",
			"npm": {
				"name": "package-name",
				"version": "0.0.15"
			}
		},
		{
			"downloadUrl": "https://our.nexus.server/nexus/repository/hosted-repository/package-folder/-/package-name-0.0.15.tgz",
			"path": "package-name/-/package-name-0.0.15.tgz",
			"id": "id-of-package-from-hosted",
			"repository": "hosted-repository",
			"format": "npm",
			"checksum": {
				"sha1": "sha-of-hosted-package"
			},
			"contentType": "application/gzip",
			"lastModified": "2024-01-28T06:21:26.851+00:00",
			"npm": {
				"name": "package-name",
				"version": "0.0.15"
			}
		}
	]
}

Effectively retrieving a package with the same name and version, despite the fact that it already existed there.

So my question is, is this by design? Or can we change the priority where the packages are looked for first?

Thank you.

2

@guilherme.m.m.f.silva The order of group members is used for many aspects of this kind of prioritization. It’s always possible there’s some kind of edge case, but can you confirm that you have the Hosted repository as the first member? Your diagram makes it look like maybe it’s not.

(In general, hosted repository fetches are also a lot faster than proxies, so as long as it’s not misaligned with your priorities, it’s good to put the hosted repos first.)

If the set of packages is small and you’re still running into problems, you might also consider using a Routing Rule to prevent the artifacts from ever being found in the proxy, if that is what you intend.

3

Hi @mprescott,

If I’m understanding you correctly, you’re saying the actual order of the list of the repos in the Group repos matters for the way in which Nexus decides where to fetch a specific package. Is that correct? I honestly did not know that was the case. Is this anywhere in the documentation?

4

This was it! I never knew that Group repositories had priorities, clearly missing the entire reason why up and down arrows exist between the Member Repositories “Available” and “Members” lists on the configuration :slight_smile:

After pushing the hosted repo to first place we retested and the package started being fetched from it. Thank you.