928881 - django-cache-machine fails to invalidate cache correctly

Status: VERIFIED FIXED

(Marketplace Graveyard :: General, defect, P1)

Description

[Mathieu Pillard [:mat]]

We've had issues recently with caches not being invalidated correctly. See for instance bug 928353.

I strongly suspect it's because django-cache-machine 0.8 (we upgraded in bug 883477). It introduces multi-db support, to be able to have different cache keys depending on the database. Unfortunately, I don't know if it's by design, but it appears that cache is not properly invalidated for a cache key depending on a slave (i.e., most reads) when you save an object - it seems it's only correctly invalidated for the master.

If that's the case, we need to fix that, either by fixing this in django-cache-machine itself (if it's be design, then we need to find a generic way to allow both behaviors) or finding a way to fix this on our end without having to write cache_key methods for every model we have.

Comment 1

[Mathieu Pillard [:mat]]

Reproduced the problem locally, it's definitely a bug in django-cache-machine.

Looking at the code and the discussions in https://github.com/jbalogh/django-cache-machine/issues/43 and https://github.com/jbalogh/django-cache-machine/pull/36, it looks like it's because of FETCH_BY_ID.

FETCH_BY_ID prevents cache duplication by doing a separate query for the id and then another for the object themselves, by id. It's a cool (undocumented) trick, but multi-db support for it is broken : only the first query, the one for the ids, seems to be invalidated on the slave databases :(

Disabling it should work but I'm not sure of the extra load it can cause.

Comment 2

[Mathieu Pillard [:mat]]

Fixed in https://github.com/mozilla/zamboni/commit/0ba355e6fdb96236d0cfa0f27e6a06ed156407b1

STR:
- Submit and push to public an app on -dev
- In another browser (to make sure cookies are not shared) verify that the URL to see the app on the consumer pages work
- Edit your app description back in your first browser
- Reload the consumer page on your second browser, verify that your updated description appears (if you need to wait more than a few seconds for the change to appear on the consumer side, then this bug is not fixed)

Comment 3

[Victor Carciu]

Based on STRs , this bug is not fixed because the change are not displayed in the other browser even if I tried after 30 seconds : http://screencast.com/t/fcLoT579k4

Comment 4

[Mathieu Pillard [:mat]]

It works fine for me :(

I wonder if it's because of the language difference between your two browsers, can you make sure to use the same language in both ? (add ?lang=en-US in the URL for both)

Comment 5

[Victor Carciu]

(In reply to Mathieu Pillard [:mat] from comment #4)
> It works fine for me :(
> 
> I wonder if it's because of the language difference between your two
> browsers, can you make sure to use the same language in both ? (add
> ?lang=en-US in the URL for both)

You are right, after language changes, everything is working on second browser. Can I close the bug ?

Comment 6

[Mathieu Pillard [:mat]]

Yes, different languages are cached separately, and always have been, so it's not a regression.

Comment 7

[Victor Carciu]

Thank you! Varified as fixed.