Caching used for pages which shouldn't be cached

Bug #1543827 reported by Hachmann on 2016-02-09
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Inkscape-website
Critical
Martin Owens

Bug Description

I've just updated the website update news article.

After editing and saving, I noticed that the news hasn't changed yet on the News page, but on the front page, it had.
So I wasn't sure if maybe only part of my edits had been saved (title and summary).

I then switched to editing the news via the Edit news button again, and in the edit form, the contents was still the old one, not the one I had saved.

In the admin interface, I was able to see that my edits had indeed been saved. So I assume that there is some undesired caching going on here.

This is really bad if an editor notices an error and wants to come back to correct it after publishing, because they might think their edits were not saved, or were lost.+

List of most important affected pages:
- News editing/translation page (with prefilled form!) - FIXED
- Profile page (e.g. images, subscription status)
- Message Inbox - FIXED
- Message info thing with js on every page - FIXED
- Paste Edit (reported by Bryce) - FIXED
- Possibly: IRC log not displaying nicely formatted right away - FIXED
- Adding Team member
- Deleting comment (via admin - can this work at all?)

Martin Owens (doctormo) wrote :

Additional: I noticed the news pages were cached because even though I was logged in, I got no editor buttons.

Changed in inkscape-web:
status: New → Confirmed
importance: Undecided → High
Hachmann (marenhachmann) wrote :

This also applies to my own profile, which is weird when I friend/unfriend someone, want to know about my quota or have deleted an image that is still in the list of recent uploads after deletion.

Martin Owens (doctormo) wrote :

There are two ways to fix this. Either one can set the cache to zero for some views, certain views. And the other is to reset the cache when actions are taken so page cache is cleared at the right times.

The former is easier and the later is proper.

Hachmann (marenhachmann) wrote :

Yes, I know the general principle.

The latter will require quite a bit of detail work - requires to add a callback for updating all the right places from all the right places...

Hachmann (marenhachmann) on 2016-03-20
summary: - News editing seems to be cached
+ Caching used for pages which shouldn't be cached
Hachmann (marenhachmann) wrote :

And two more:

The new 'new messages alert' never stops flashing and doesn't update the number of new messages when I reload the page after marking all my messages as read. This is really annoying... (works well locally - haven't tested the sound yet ;) )

The messages page is cached, too, btw... So if I return to my checked messages, they are all back again. Zombies!

description: updated
Martin Owens (doctormo) wrote :

Hmm, I never got it to fail with over flashing, but maybe it's doing something wrong with the json. You can open a bug report and paste in what you see in /alerts/json/ which should give you what the script sees.

Hachmann (marenhachmann) wrote :

I'm quite sure it's the caching. It works great locally.

Hachmann (marenhachmann) wrote :

Not sure why, but with Sylvain's latest two Publish messages, the flashing stopped after marking as viewed and reloading. Did you change anything, Martin?

Martin Owens (doctormo) wrote :

No but it could still be caching. :-)

Hachmann (marenhachmann) wrote :

Yes, I could have accidentally hit the exact refresh time...

Hachmann (marenhachmann) wrote :

Tested again, the json doesn't update, so it's probably cached, too.

Martin Owens (doctormo) wrote :

Yeah I'm coming to the conclusion that the caching is /really/ f*in aggressive. Every view is included, even if it outputs json, or is an edit response. Ham fisted view caching IMO.

Hachmann (marenhachmann) on 2016-03-25
description: updated
Hachmann (marenhachmann) wrote :

The new news also seem to be cached - but as we access the admin interface directly, they are at least not cached for editing.
Only I still get to see the old page and a message 'This page has not been published yet', even after publishing. This state only lasts for a few minutes, but it's still a bit confusing.

Martin Owens (doctormo) wrote :

I had trouble with publishing, I eventually went into the back end to make sure it was published.

Hachmann (marenhachmann) wrote :

That's what I did, too...

Hachmann (marenhachmann) wrote :

I got that 'unpublished' warning message even after the contents was available on the website from a 'private browsing' window.

Martin Owens (doctormo) on 2016-04-29
Changed in inkscape-web:
importance: High → Critical
Martin Owens (doctormo) wrote :

I've added (and pushed live) a new caching middleware. (also removed the old csrf hack middleware). The idea of this new middleware is that it records the caching keys of generic views like news and then invalidates that view's cache when the object's change. I installed memcached locally so I could test this all the way through since it's a delicate piece.

Please test, look for speed degradation as well as pages not changing when objects are saved... some of our views don't use the predictable object and object_list context variable names, and so far, this is what I'm depending on in order to record the cache keys.

Hachmann (marenhachmann) wrote :

Not sure if it's broken caching, intended caching or broken functionality:
I just copied my MultiBool extension to my Extensions gallery, and it's not there (10 minutes).

In the admin interface for the gallery, both are listed.

Hachmann (marenhachmann) wrote :

It's there now. So this might be within the intended caching interval?

Martin Owens (doctormo) wrote :

This really depends on the view, not all views will be covered by the new middleware (and also previous caches won't be taken into account, so if it cached before the update...) the best way to know FOR SURE, is to add ?something to the end of the url and test. If it changes, it's the caching.

Hachmann (marenhachmann) wrote :

Martin, I wasn't able to find the ?something string again... I know it changed, and is no longer that really long one, but couldn't locate the new one.

Comments also seem to take some time to show up - is there a fifteen minute minimum somewhere? It seems to take around that amount of time for most things.

Martin Owens (doctormo) wrote :

Caching's been toasted again on live?

:-(

Hachmann (marenhachmann) on 2016-05-08
description: updated
Bryce Harrington (bryce) wrote :

I suspect I'm being hit by the slow moving zombie, aka aggressive caching. I thought the site was bugged, and kept re-editing stuff over and over. Would be great if we could tune the caching a bit better.

Martin Owens (doctormo) wrote :

Part of the problem is that django-cms would die horribly without full page caching, but the damn thing applies to EVERY view everywhere. So turning it off one by one on pages. (or trying to find a way to get caching to invalidate itself when needed). The added bonus is just how hard it is to test caching in the test suites.

Hachmann (marenhachmann) on 2016-05-24
description: updated
Martin Owens (doctormo) wrote :

The auto caching invalidation was just fixed (pushed live) I think this will help news editing and paste editing.

Hachmann (marenhachmann) wrote :

@Martin: is it maybe intentional that the user profile page doesn't update for new uploads right away?

description: updated
Hachmann (marenhachmann) on 2016-06-26
Changed in inkscape-web:
status: Confirmed → In Progress
assignee: nobody → Martin Owens (doctormo)
Martin Owens (doctormo) wrote :

No, it's just an extra manual step because user profile page binds to user-pk urls and not to resource-user-pk, you'd be surprised how hard it is to join these things. Although invalidating everyone's user profile at the same time is an option.

Martin Owens (doctormo) wrote :

r1375 includes a new templatetag which tracks every used resource in any url where it's being used. This includes the user profile page, any gallery page, any cms page with a gallery plugin (although cms caching is not invalidated, so that probably gets in the way there)

This feature should allow great cache invalidating precision. Creating new resources does not yet update these pages, this is a more complex issue.

Hachmann (marenhachmann) wrote :

Cache invalidation doesn't seem to work when a team member is added.

Martin Owens (doctormo) wrote :

There's a huge pile of hours that I've sunk into the cache invalidation on creation. I've got a somewhat workable model for what needs to happen, but it needs more work and the tests all need proofing properly.

Hachmann (marenhachmann) wrote :

Guess I hoped it was just a matter of adding a decorator... It's not an urgent problem.

Hachmann (marenhachmann) on 2016-09-08
description: updated
Martin Owens (doctormo) wrote :

Regarding comment deletion 'working', yes it can. But it depends on the comment queryset being tracked when displayed on a page.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers