Does overwriting snupkgs on Push make sense?

[donnie-msft]

nupkg behavior: If a nupkg exists, a consistent response of 409 will be returned. Client handles this differently based on whether -SkipDuplicate is provided as part of the push.

snupkg behavior: snupkg duplicates can sometimes behaves differently than nupkg duplicates (as is the case with nuget.org):

• If a snupkg already exists when pushed, nuget.org will simply overwrite it, validation will be re-ran on this snupkg, and a success response (HTTP-201) is returned.

• A special case is if server validation is currently executing on this snupkg (as it does immediately after a push), another push of the snupkg causes the server to return this duplicate error:

Response status code does not indicate success: 409 (It looks like there is another copy of this symbols package pending validation(s). Please wait for the validation(s) to finish before trying to replace the symbols package.).

Describe the solution you'd like

It should be discussed whether nuget.org should continue overwriting snupkgs when they are pushed. At a minimum, the existing experience is inconsistent with nupkgs.

Some initial thoughts and discussion points:
Minimal use-case: The (only?) scenario where updating ("patching") an existing snupkg is if you didn't include all the PDBs in the original snupkg, and subsequently added them. Is this scenario common? Should we require them to Delete their symbols through "Delete Symbols" button on nuget.org before they can then push the snupkg again without a 409 Conflict?

Version guidance: Assumption here is that we prefer to not require a new package version when adding additional symbols to a snupkg. Thus, a user can incrementally fill a snupkg with PDBs as long as they don't modify the DLL.

Server workload concern: pushing N nupkgs (say N=100) will involuntarily update <=100 snupkgs and trigger <=100 validations of symbols that have already been through validation (assuming this trigger happens even if there are no changes to the snupkg).

Additional context

NuGet Client Issue where this discussion came up: NuGet/Home#8148
Discussion that lead to this issue by: @cristinamanum, @karann-msft, @rrelyea, @donnie-msft

[loic-sharma]

Minimal use-case: The (only?) scenario where updating ("patching") an existing snupkg is if you didn't include all the PDBs in the original snupkg, and subsequently added them.

For security reasons, you can only debug a DLL with the portable PDB that was built with that DLL. You cannot rebuild the same source code to generate its PDBs. In other words, that scenario is more like "you didn't include all the PDBs in the original snupkg, but you happened to have kept the PDBs around, and subsequently added them.".

[donnie-msft]

Minimal use-case: The (only?) scenario where updating ("patching") an existing snupkg is if you didn't include all the PDBs in the original snupkg, and subsequently added them.

Keep in mind that for security reasons you can only debug a DLL with the PDB that was built with that DLL. I cannot rebuild the DLLs' source code to generate its PDBs. In other words, that scenario is more like "you didn't include all the PDBs in the original snupkg, but happened to have kept the PDBs around, and subsequently added them.".

Yes, so how frequently is that use-case coming up? Are you agreeing that it's minimal, or are you saying that it's important to continue to support despite the inconsistency noted above?

[loic-sharma]

I'm agreeing that it sounds minimal, but we should look at telemetry to be sure.

[StephenCleary]

I think it makes more sense to have snupkgs 409 just like nupkgs do. That behavior would work better for CI scenarios: SkipDuplicate could be used to skip publishing until the version number changes.

[donnie-msft]

Related issue for Client would make fewer snupkg pushes (in the case where the nupkg exists on the server, then we won't automatically try pushing snupkgs) if this issue gets a PR: NuGet/Home#9647

Meaning, the only scenario for this issue would be pushing a snupkg directly that already exists on nuget.org.

[natemcmaster]

I think it makes more sense to have snupkgs 409 just like nupkgs do. That behavior would work better for CI scenarios: SkipDuplicate could be used to skip publishing until the version number changes.

+1 for this. I think this is the least surprising behavior from a my perspective as a user. I ran into this bug myself because I expected -SkipDuplicate to apply the same behavior. There may be use cases for overwriting existing snupkg, but if I had to guess, I'd say that is a less common scenario and should be an opt-in behavior like -Overwrite, instead of the default behavior.