Artifactory NuGet install not getting latest package version

Question

I am experiencing a problem when installing NuGet packages from a self-hosted Artifactory. When a package ID gets above thirty unique versions the NuGet install command becomes unable to identify the latest version. Examining the log from NuGet install command I can see it making two web requests.

GET https://artifactory.local/artifactory/api/nuget/<repository>/FindPackagesById()?id='<package ID>'
OK https://artifactory.local/artifactory/api/nuget/<repository>/FindPackagesById()?id='<package ID>' 815ms
GET https://artifactory.local/artifactory/api/nuget/<repository>/FindPackagesById()?$skip=80&id='<package ID>'
OK https://artifactory.local/artifactory/api/nuget/<repository>/FindPackagesById()?$skip=80&id='<package ID>' 209 ms

When I run these commands I get a XML feed response with thirty and zero entries respectively. If I adjust the '$skip' parameter in the second request to thirty I see my most recent packages.

Is Artifactory incorrectly implementing the NuGet API FindPackagesById method by not returning eighty entries?

Specs

• Artifactory version 4.12.01
• NuGet command line version 3.4.4.1321

Answer 1

The current implementation with Local and Virtual Nuget repositories mandates a max of 80 results per page. The first OData feed response (for the first request that has no $skip param in it) should be able to return 80 entries, providing that there are at least 80 versions of the package.

A problem that Artifactory currently has and that we are aware of happens when a single package (same package ID) is contained within multiple different repositories, and when the request is sent via a Virtual repository that aggregates those repositories. If the single package has more than 80 versions, Artifactory returns a pagination link with $skip=80 on the first response. The issue is that Artifactory (wrongly) assumes that a certain package ID will only exist in one repository under the virtual repo, and hence sends $skip=n to all the aggregated repos one by one, so skip=1 actually skips two entities, skip=2 actually skips 4, and skip=n essentially becomes skip=2n. This bug is reported here and will be fixed in the coming months:

https://www.jfrog.com/jira/browse/RTFACT-12379

If this doesn't sound like your problem, please share how many versions exist for the package you are trying to install, whether you are using a virtual repository or not, and whether the same package exists in more than one repository under the corresponding virtual repo.

Until RTFACT-12379 is fixed, the current (not so ideal) workarounds for this are either not using a virtual repository to install packages that have more than 80 versions, or making sure that a certain package does not exist in more than one repository.