Package Upload Process is reportedly slow

[maartenba]

From @csharpfritz on March 24, 2015 18:49

This morning there was a bit of chatter on Twitter and GitHub about the performance of the package upload process:

https://github.com/fsharp/FAKE/issues/710#issuecomment-85558132

This sounds like a known issue, with Frans Bouma making similar complaints on twitter whenever he updates his packages. https://twitter.com/FransBouma/status/580059847032487936

Copied from original issue: NuGet/Home#268

[maartenba]

From @forki on April 8, 2015 11:36

as described in https://github.com/fsharp/FAKE/issues/710#issuecomment-85648279:

"@yishaigalatzer thanks for responding here. I really appreciate that.

The repro is not really trivial, but this is what we know (seen over 100 times...):

• release a new nuget package version
• run "nuget.exe install" immediately after nuget push
• it fails to install on some machines (I assume depending on which server the load balancer gives you!? or some caching? but not on all machines)

The install process consists of 3 major parts: 1) determine which version we want to install 2) download that version 3) run the install process

Since we don't specify a version, nuget.exe will assume "latest". So it asks the service for 1) and returns the latest. Now in 2) it tries to download that concrete version. This step fails, since the download server doesn't have the version available.

After a couple of minutes (maybe 15) the same "nuget install" works on all machines."

[maartenba]

From @khellang on April 8, 2015 12:0

I was just bitten by this:

1. Installed Serilog.Sinks.Literate version 1.0.1 (a couple of minutes after the package was pushed)
2. Pushed to master
3. CI build failed on nuget restore

So it's not just installation; even after the package was successfully installed, the package restore failed.

[maartenba]

From @yishaigalatzer on April 8, 2015 18:59

@khellang yes, these are different code paths. And I'm assuming its a related but slightly different problem. Can you please share how it failed? Logs etc.

[maartenba]

From @forki on April 9, 2015 7:20

yes, these are different code paths

I don't think this is important since it's not a client issue. It's probably server side.

[maartenba]

From @khellang on April 9, 2015 11:51

@yishaigalatzer There's not much in the logs. I get

Unable to find version '1.0.1' of package 'Serilog.Sinks.Literate'.

And the build fails because of the missing package. Typically

'Serilog.Configuration.LoggerSinkConfiguration' does not contain a definition for 'LiterateConsole' and no extension method 'LiterateConsole' accepting a first argument of type 'Serilog.Configuration.LoggerSinkConfiguration' could be found (are you missing a using directive or an assembly reference?) [13:24:23][Step 1/1] 3) CS1593: Program.cs(23,44): Delegate 'System.Func' does not take 1 arguments

I think this is pretty consistent with what people are seeing with Paket and FAKE etc.

[maartenba]

From @yishaigalatzer on April 9, 2015 14:29

@forki different code paths in the server.

[maartenba]

From @yishaigalatzer on May 12, 2015 23:26

@johnataylor where are we standing on this?

[maartenba]

From @neurospeech on August 6, 2015 13:52

We have fixed this issue by creating a proxy that rewrites one of failing package query using OData, may be NuGet team can look at it and find the problem. Here is a proxy server that rewrites the query and works perfectly. https://github.com/neurospeech/NuGetProxy

[maartenba]

Upload should be better now. Still takes a while for the index to be updated but that's the next thing to tackle.