All users were logged out of Bugzilla on October 13th, 2018

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

RESOLVED WORKSFORME

Status

P1
major
RESOLVED WORKSFORME
5 years ago
5 years ago

People

(Reporter: vcarciu, Assigned: chuck)

Tracking

({regression})

Avenir
2013-09-24
x86_64
Windows 7
regression
Points:
---

Details

(Whiteboard: [pinning], URL)

(Reporter)

Description

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

Comment 1

5 years ago
This is the pinning issue that we were having with the API. Can you still reproduce it?
Component: Admin Tools → API
Flags: needinfo?(vcarciu)

Comment 2

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

Comment 3

5 years ago
This updates the cache rewriting for collection creation:

https://github.com/mozilla/rocketfuel/commit/d1f49ec405b74c4f682ac2d500a6fb7722e2d631

Comment 4

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

Comment 6

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

Updated

5 years ago
Priority: -- → P1
(Assignee)

Comment 7

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

Comment 8

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

Comment 9

5 years ago
I was unable to reproduce this today. If I manage to get it to happen, I'll mark it down.
Flags: needinfo?(mattbasta)
(Assignee)

Updated

5 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.