steps to reproduce: 1. Create a collection or Load https://marketplace.firefox.com/curation/collection/test 2. Add a bunch of apps 3. Try to reorder the listed apps expected behavior: Reorder is successful observed behavior: Reorder fails with a 400 POST https://marketplace.firefox.com/api/v1/rocketfuel/collections/317/reorder/ [HTTP/1.1 400 BAD REQUEST 5326ms] ashes: ID: f3498
Note that the problem happens only if the reordering is attempted immediately after adding some apps to the collection. Reordering apps in an existing collection seems to work.
From Scott in bug 952589: > Thought things are moving along much smoother than last week, I am unfortunately still running into sporadic cases where the tool won't allow me to [sic] re-order apps. I'll keep attaching details and logs as I encounter them. > Here's the log for Peru's Home page: 96dcf
At this point I'm tempted to just .no_cache() the whole thing and be done with it...
Assignee: nobody → mpillard
Component: Admin Tools → API
Priority: -- → P1
Might not be a cache issue but a master/slave issue. Tentative fix in https://github.com/mozilla/zamboni/pull/1583
(Hopefully) fixed in https://github.com/mozilla/zamboni/commit/af4760040e4da5d5e8ac799034f356cc52b1048d This is now testable on -dev and should land in production tuesday. Note: Before re-ordering, make sure to wait for the confirmation notification that pops up after adding app(s).
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2014-01-07
STR: 1. Load https://bugzilla.mozilla.org/show_bug.cgi?id=951946#c6 2. Add a bunch of apps (I added 10) 3. After the 'App added to collection' user message is shown, try to reorder apps 4. Reordering fails 5. Reload the collection details page 6. Try reordering again observed behavior: Reordering fails with a POST https://marketplace-dev.allizom.org/api/v1/rocketfuel/collections/223/reorder/ [HTTP/1.1 400 BAD REQUEST 1333ms] ID: 918ca request headers: https://www.dropbox.com/s/epyfg4n6tgk3g36/Screenshot%202014-01-02%2013.23.54.png response headers: https://www.dropbox.com/s/yyk6k3w4vz9iwaf/Screenshot%202014-01-02%2013.24.17.png
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I disabled cache in https://github.com/mozilla/zamboni/commit/207d4b6e1c66b516d8095b54c4847f82442ab676 How does it look now Krupa ? I couldn't get it to fail on -dev.
(In reply to Mathieu Pillard [:mat] from comment #8) > I disabled cache in > https://github.com/mozilla/zamboni/commit/ > 207d4b6e1c66b516d8095b54c4847f82442ab676 > > How does it look now Krupa ? I couldn't get it to fail on -dev. I can still reproduce the issue with different STR 1. Add few apps to a collection (https://marketplace-dev.allizom.org/curation/collection/blah-blah) 2. Reorder apps 3. Delete one app 4. Reorder apps after step# 2, reorder is successful but after step# 4, reorder fails with a 400. ID: af0fd
I've pushed https://github.com/mozilla/zamboni/commit/11b1cca1d9e81c6e884d24e9fd7d5edaab4aa48f to make the error returned less verbose. I can't reproduce STR from comment 9 :( Something strange about those ashes: it says the first reorder (and subsequent ones) failed right away, I don't see the successful attempt you described.
In case it's related, I just encountered the inability to add apps to the Featured Games page in Italy. https://marketplace.firefox.com/curation/collection/games-italy-feat Log: ceb86
(In reply to sdevaney from comment #11) > In case it's related, I just encountered the inability to add apps to the > Featured Games page in Italy. > > https://marketplace.firefox.com/curation/collection/games-italy-feat > > Log: ceb86 The logs tell me that you tried to add "Command & Conquer Tiberium Alliances" but that app already existed in the collection. Can you confirm that was what happened?
Hmm... I don't think so. that's not even possible, right? You need to be able to search for an app to add it. And if the app is already part of the collection, it doesn't appear in search.
reordering works now. I wasn't able to reproduce the issue from comment 9 anymore.
Ok let's close this. There are 3 changes that were made since the beginning on this issue in another bug: - Caching invalidation fixes - Master/Slave pinning fixes - Caching bypass when checking before re-ordering It should make everything more robust, and since krupa can't reproduce the issue now, I'm inclined to believe we are in good shape now. sdevaney: please tell us if anything is still broken after Tuesday around noon PST, when my fixes land in production.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago → 5 years ago
Resolution: --- → FIXED
Verified as fixed in https://marketplace.allizom.org/curation/ on FF29 (Win 7). Postfix screenshot http://screencast.com/t/BLiZrW5WDk Closing bug.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.