bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Rocketfuel API returns spurious uniqueness errors on PATCH

RESOLVED DUPLICATE of bug 914874

Status

Marketplace
API
RESOLVED DUPLICATE of bug 914874
5 years ago
5 years ago

People

(Reporter: basta, Unassigned)

Tracking

x86
Mac OS X
Points:
---

Details

(Reporter)

Description

5 years ago
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

5 years ago
Assignee: nobody → mpillard
Blocks: 894417
I'll take it back on monday if nobody jumped on it in the meantime.
Assignee: mpillard → nobody
No longer blocks: 894417
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
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 3

5 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 → ---
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

5 years ago
I'm not on PTO, I'm just OOTO. :P

I'll build a test case after I get bug 913003 fixed.
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

5 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

5 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?
See discussion in bug 914874 this is essentially the same thing.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 914874
You need to log in before you can comment on or make changes to this bug.