Infer push endpoint by PackageType instead of extension

donnie-msft commented 4 years ago

Using the file extension to determine whether symbols are being pushed is not reliable.

Repro:

Pack a .snupkg then change the file extension to .symbols.nupkg. Push the .symbols.nupkg.

Expected:

On push

-SymbolSource is required parameter since this is a Symbol push.
Error that the symbols.nupkg is invalid (PackageType differs from extension).

Actual:

Pushing ConsoleApp12.1.0.13.snupkg to 'https://dev.nugettest.org/api/v2/package'... PUT https://dev.nugettest.org/api/v2/package/ BadRequest https://dev.nugettest.org/api/v2/package/ 541ms error: Response status code does not indicate success: 400 (Snupkg upload failed. Please use latest NuGet clients (v 4.9.0 or above) and a V3 endpoint to push Symbol packages. For details, refer https://docs.microsoft.com/nuget/create-packages/symbol-packages-snupkg).

Created after a discussion with @joelverhagen & @loic-sharma /cc @zkat

zkat commented 4 years ago

@joelverhagen @loic-sharma @donnie-msft Can you tell us more about this scenario and what prompted it? What does the service return? At first glance, this seems like a server-side issue to me?

joelverhagen commented 4 years ago

I don't know the full thing that prompted this, but my understanding was that Donnie was doing some testing of push and encountered a situation where client pushes a package with package type SymbolsPackage (clearly a symbols package, irrespective of file name) to the package publish endpoint. The server rejected this because, per protocol symbols, packages must be pushed to the dedicated symbols endpoint to be ingested properly.

Consider the service index: https://api.nuget.org/v3/index.json

Client could, theoretically, check the package types of the pushed file and use the appropriate push endpoint depending on the package types.

This is the .nuspec from a .snupkg:

The corresponding .nupkg does not have a package type.

NuGet / Home