Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

40 NuGet bug #30

Open
jeopal opened this issue May 4, 2018 · 2 comments
Open

40 NuGet bug #30

jeopal opened this issue May 4, 2018 · 2 comments

Comments

@jeopal
Copy link

jeopal commented May 4, 2018

When 40 versions of a NuGet have been published to a NuGet v2 feed, Find-Package, Install-Package, and Save-Package fail because they return duplicate copies of each version.

@jianyunt
Copy link
Contributor

jianyunt commented May 4, 2018

@jeopal want does "40 versions of a NuGet" mean?

@zarenner
Copy link

zarenner commented May 4, 2018

More specifically:

NuGetProvider expects a server to implement $top/$skip on the FindPackagesById API. When a server does not, and the number of package versions matches some multiples of the $top page size, such as 40 or 160 (I'm not sure why 80 and 120 didn't repro for me), NuGetProvider performs multiple additional calls with $top=40, and $skip up to 160. Presumably it's looking for another page since the number of results it got back is exactly the page size. The server returns the exact same results (all of them) each time, and the NuGetProvider counts them as duplicate entries.

VSTS Package Management is an example of a server that does not support $top/$skip on FindPackagesById today. It's arguable that the primary bug here is on VSTS for not supporting top/skip, but this was somewhat intentional by VSTS due to performance/scale concerns on feeds with many package versions. That is, VSTS is highly optimized to be able to return all versions at once (e.g. for the v3 flat package index api), so supporting clients that require using extremely low page sizes (40) on feeds with hundreds or thousands of versions is highly detrimental.

I haven't looked at the NuGetProvider code so I can't comment in detail, but some possible fixes on the NuGetProvider side here would be to:

  1. Ignore duplicate versions returned by the server
  2. Understand that when the exact same result set is returned twice in a row, the server does not support paging. 1 is still necessary as the number of versions could have changed between calls.
  3. Not use FindPackagesById() for Install-Package at least, as there exists the more appropriate V2 Packages(Id, Version) API for that. Doesn't fix Find-Package.
  4. Support the NuGet v3 protocol. Doesn't fix V2 users, but there are few reasons (other than NuGetProvider support) why anyone should be using V2 nowaways AFAIK.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants