Closed Bug 917336 Opened 11 years ago Closed 11 years ago

[rocketfuel] Collections list API does not show return newly created collections

Categories

(Marketplace Graveyard :: API, defect, P1)

Avenir
x86_64
Windows 7

Tracking

(Not tracked)

RESOLVED WORKSFORME
2013-09-24

People

(Reporter: vcarciu, Assigned: chuck)

References

()

Details

(Keywords: regression, Whiteboard: [pinning])

Prerequisites:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0

Steps to reproduce:
1. Go to https://marketplace-dev.allizom.org/curation/new_collection?type=basic ,create a new collection and make it public
2.Go to https://marketplace-dev.allizom.org/curation in order to see the newly created collection

Expected results:
1.The collection is displayed in Curation tool

Actual results:
Collection is not displayed in Curation tool

Please see screencast for this bug : http://screencast.com/t/TS8rlYdL
Lod ID: 3c405

Notes: 
Reproducible for both -dev and Stage
This is the pinning issue that we were having with the API. Can you still reproduce it?
Component: Admin Tools → API
Flags: needinfo?(vcarciu)
Actually nevermind, this is also partially caused by a lack of cache rewriting. Keeping the bug here until the cache rewriting is in place.

We need the cache rewriting to update all keys in the request cache that match the base URL for the collections list API. Keys should be ignored if any truthy query params for region, category, or carrier does not match the corresponding property on the collection and the corresponding property is truthy (unless the property is category, in which case it must always match). E.g.:

Rewrite: ?cat=&region=&carrier= | {cat:null, region:null, carrier:null}
Ignore: ?cat=foo&region=&carrier= | {cat:null, region:null, carrier:null}
Rewrite: ?cat=foo&region=&carrier= | {cat:'foo', region:null, carrier:null}
Rewrite: ?cat=&region=foo&carrier=bar | {cat:null, region:null, carrier:null}
Rewrite: ?cat=&region=foo&carrier=bar | {cat:null, region:'foo', carrier:'bar'}
Ignore: ?cat=&region=foo&carrier=bar | {cat:null, region:'abc', carrier:null}

We should also add cache rewriting for deletions. Deletions should rewrite all request cache entries whose base URL matches the collection list API and remove any collection whose ID matches the deleted collection's ID.
Component: API → Admin Tools
Flags: needinfo?(vcarciu)
Summary: Newly created collections are not displayed in Curation tool → [rocketfuel] Add cache rewriting for newly created collections.
This updates the cache rewriting for collection creation:

https://github.com/mozilla/rocketfuel/commit/d1f49ec405b74c4f682ac2d500a6fb7722e2d631
And after closer inspection, it does seem that we do indeed have cache rewriting in place for deletion.

I inspected the logs and it does seem like this is the pinning issue again. Moving back to the API component.
Component: Admin Tools → API
Summary: [rocketfuel] Add cache rewriting for newly created collections. → [rocketfuel] Collections list API does not show return newly created collections
Whiteboard: [pinning]
Could it be default ORM caching and not pinning?
That's entirely possible. I'm assuming it's pinning since we've experienced no issues with making updates, just creating new collections (and we've had so many pinning issues so far).
Priority: -- → P1
I was having trouble writing a failing test case here, even with a full master/slave configuration locally.

So as a helpful debugging step, I added an API-Pinned header indicating whether the request was pinned to master.

https://github.com/mozilla/zamboni/compare/5107d662dd8a...a0b8d570a6fc

Mr. Basta: can you verify that the value of that header is True in the problematic requests? If so, we will know for certain that it is not related to pinning.
Assignee: nobody → charmston
Status: NEW → ASSIGNED
Flags: needinfo?(mattbasta)
(In reply to Chuck Harmston [:chuck] from comment #7)
> Mr. Basta:

http://i.imgur.com/nHzQEQz.jpg

> can you verify that the value of that header is True in the
> problematic requests? If so, we will know for certain that it is not related
> to pinning.

I shall do it today.
I was unable to reproduce this today. If I manage to get it to happen, I'll mark it down.
Flags: needinfo?(mattbasta)
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.