Nugetgallery: Wrong error behavior during upload if blob already exists in storage

Created on 25 Jan 2019  路  4Comments  路  Source: NuGet/NuGetGallery

Repro steps:

  1. Find a package that is not in the DB, but the file exists in packages container
  2. Try to upload a package with same name

Result:
You get a message: "There is a conflict with the ID and version of your package and another package. Please change your package's ID or version and try again."

This error message is wrong since the situation is a server bug and not "conflict with another id".
We should 500.

Gallery UI Priority - 3 Bug

Most helpful comment

@skofman1 - We implemented this because it is possible that multiple packages map to the same packages container URI.

E.g. mypackage.1 1.0.0 vs mypackage 1.1.0.0

As such, this particular symptom could either be

  • packages container was not cleaned up (500)
  • conflicting ID/version (409)

I don't think we should change this to a 500 because in the case that a user runs into the conflict case, the error message can help them fix the issue without our intervention.

The long term solution here is that we should switch to a different storage model for the container that doesn't have this potential for conflicts.

As a short term mitigation, we could consider cleaning the packages container by deleting packages that don't exist in the gallery DB. (I would be cautious about doing this based on V3 as we know it can skip packages occasionally.)

All 4 comments

We could also create a V3 validation that detects these packages (in the DB but not in the packages container) so that we can fix these issues proactively. @scottbommarito

@skofman1 - We implemented this because it is possible that multiple packages map to the same packages container URI.

E.g. mypackage.1 1.0.0 vs mypackage 1.1.0.0

As such, this particular symptom could either be

  • packages container was not cleaned up (500)
  • conflicting ID/version (409)

I don't think we should change this to a 500 because in the case that a user runs into the conflict case, the error message can help them fix the issue without our intervention.

The long term solution here is that we should switch to a different storage model for the container that doesn't have this potential for conflicts.

As a short term mitigation, we could consider cleaning the packages container by deleting packages that don't exist in the gallery DB. (I would be cautious about doing this based on V3 as we know it can skip packages occasionally.)

I would be cautious about doing this based on V3 as we know it can skip packages occasionally

I thought the only actions that were skipped by V3 were package creations/edits - have we had cases of skipped package deletions?

@scottbommarito , thanks for reminding me about the package name collisions issue.. the right solution is to move to flat container model here.

Was this page helpful?
0 / 5 - 0 ratings