Nuget metadata endpoint returns the wrong `upper` or `lower` version
Summary
Packages::Nuget::PackageFinder
doesn't order the result by the most recent ones. The order is thus dictated by the database (the most probable is that it uses the primary key)
and
The finder has an Application Limits of 50 packages.
gives us
when request the metadata for a given nuget package name, the lower
and upper
versions can be wrong and this will create a ~bug on nuget
CLI as it will not see all the package versions.
Steps to reproduce
- Create a project
- Upload 50+ versions for the same nuget package name
- Query: /api/v4/projects/X/packages/nuget/metadata/package_name/index.json
-
upper
or/andlower
fields are reporting the wrong value
Example Project
(If possible, please create an example project here on GitLab.com that exhibits the problematic behavior, and link to it here in the bug report)
(If you are using an older version of GitLab, this will also determine whether the bug is fixed in a more recent version)
What is the current bug behavior?
- The nuget metadata endpoint is returning the wrong
upper
/lower
fields.
What is the expected correct behavior?
- The nuget metadata endpoint should return the proper
upper
/lower
fields
Output of checks
This bug happens on GitLab.com
Possible fixes
Two ways to fix this:
- Bump the max returned packages to something like 200 or 300. (easy fix) (This has been done via !52265 (diffs))
- Implement a way to return all existing packages in the metadata endpoint. (a more complex fix)
- This will need some thought. Basically, how can we get the metadata of a nuget package for all the existing versions without using an Application Limits ? One thing doable would be to create this metadata each time the NuGet Repository receives a new version and cache somewhere where the metadata endpoint can retrieve it and return it back. For example, we could have the json document saved in object storage.
Weight of 1
for (1.)
Weight of 3
for (2.)
Possible workaround
Manually delete the oldest versions of the package using the packages UI so that we get under the 50 versions limit.
Might not be possible if those 50+ versions are in use.