Repro steps:
packages containerResult:
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.
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
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.
Most helpful comment
@skofman1 - We implemented this because it is possible that multiple packages map to the same
packagescontainer URI.E.g.
mypackage.1 1.0.0vsmypackage 1.1.0.0As such, this particular symptom could either be
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.)