Page MenuHomePhabricator

Purge varnish after GlobalUserPage is updated on the central wiki
Closed, ResolvedPublic

Description

After a GUP is updated on the central wiki, we need to purge varnish caches.

We want to queue a job on the central wiki, gathers a list of urls to purge (including language variants), and purges them.

At the same time we can queue up HTMLCacheUpdate jobs.

Event Timeline

Legoktm raised the priority of this task from to Needs Triage.
Legoktm updated the task description. (Show Details)
Legoktm added a project: GlobalUserPage.
Legoktm changed Security from none to None.
Legoktm subscribed.

Change 178779 had a related patch set uploaded (by Legoktm):
Purge caches after edits to the global user page

https://gerrit.wikimedia.org/r/178779

Patch-For-Review

Aklapper triaged this task as Medium priority.Dec 31 2014, 1:58 PM
Aklapper subscribed.

I agree this is a bug, but before declaring it a blocker for deployment I'd like to see a precise use case. What kind of edits, exactly, do really need to be urgently propagated to all wikis and can't wait a maximum of 30 days?

Not the addition of a new language to {{#babel}}, for instance, as proud as one might be of it. Nor any change in global groups, despite the "I'm in your wiki, deleting your pages" effect, because that's what special pages and logs are for. Nor anything which specifically matters for the local wiki in question, which should be in the local user page if important. We can think of other cases, but from the top of my head I can't find a really important one.

If it's necessary of course we can do it, but I tend to agree we should limit the scope of this to the degree possible so that we're not purging more often than necc

I agree this is a bug, but before declaring it a blocker for deployment I'd like to see a precise use case. What kind of edits, exactly, do really need to be urgently propagated to all wikis and can't wait a maximum of 30 days?

I don't believe there is any urgency, it's mainly so that we don't have an inconsistency between what anonymous users who hit varnish see and what logged in users see.

I don't believe there is any urgency, it's mainly so that we don't have an inconsistency between what anonymous users who hit varnish see and what logged in users see.

That's a good point. However, are we even able to ensure such a consistency with local pages? Such inconsistencies usually proved problematic when users were looking at the same very busy discussion page and saw different things (several bugs were filed in the past about WP:ANI redirects, for instance). Other than that, perhaps we just don't notice because it doesn't matter that much.

If this is fixed, all the better; but for now I'll remove this from blockers for deployment absent objections.

Change 178779 merged by jenkins-bot:
Purge caches after edits to the global user page

https://gerrit.wikimedia.org/r/178779

Legoktm claimed this task.

Change 190375 had a related patch set uploaded (by Legoktm):
Purge caches after edits to the global user page

https://gerrit.wikimedia.org/r/190375

Patch-For-Review

Change 190375 merged by jenkins-bot:
Purge caches after edits to the global user page

https://gerrit.wikimedia.org/r/190375