Closed
Bug 913539
Opened 11 years ago
Closed 11 years ago
Rocketfuel API returns spurious uniqueness errors on PATCH
Categories
(Marketplace Graveyard :: API, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 914874
People
(Reporter: basta, Unassigned)
Details
PATCH https://marketplace-dev.allizom.org/api/v1/rocketfuel/collections/225/
is_public=true
{
"collection_uniqueness":"You can not have more than one Featured Apps/Operator Shelf collection for the same category/carrier/region combination."
}
Note that the collection *is* unique (at least so far as I can see).
Updated•11 years ago
|
Assignee: nobody → mpillard
Updated•11 years ago
|
Blocks: mkt-publishtool-api
Comment 1•11 years ago
|
||
I'll take it back on monday if nobody jumped on it in the meantime.
Assignee: mpillard → nobody
No longer blocks: mkt-publishtool-api
Comment 2•11 years ago
|
||
It is a dupe with
https://marketplace-dev.allizom.org/api/v1/rocketfuel/collections/165/
Both have null carriers and categories and the `us` region.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 3•11 years ago
|
||
REOPENing because the error doesn't make any sense for updating the is_public field. The error should happen 1) at POST, though it didn't or 2) on update of region/carrier/category. We shouldn't prevent you from updating other fields because the collection is in a weird state.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 4•11 years ago
|
||
This happens on CollectionSerializer().full_clean(), which seems like the appropriate place for this validation to take place.
Can you devise a test case where you're able to show that it doesn't happen on POST? There's a chance this was just bad data that got in before the validation was in place. If there's a bug, that's where it is.
Also, go home. You're on PTO.
Reporter | ||
Comment 5•11 years ago
|
||
I'm not on PTO, I'm just OOTO. :P
I'll build a test case after I get bug 913003 fixed.
Comment 6•11 years ago
|
||
Is it possible the 2 collections were created before we started enforcing this ? (about to go home, don't want to fire up VPN to check) - we can't express properly this constraint using just SQL, so it doesn't apply for the old collections
Reporter | ||
Comment 7•11 years ago
|
||
It's possible.
It might be a smart move for us--since we've made so many changes--to wipe all of the collections on -dev just to be sure that we're not chasing ghosts. Who do we need to talk to about that?
Reporter | ||
Comment 8•11 years ago
|
||
Hmmm, yeah. Now that bug 913003 is fixed, I can't reproduce [the bug] on any new collections. Let's wipe the DB and call it a day, yeah?
Comment 9•11 years ago
|
||
See discussion in bug 914874 this is essentially the same thing.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•