Page MenuHomePhabricator

Purge Category and File description pages from file cache or squid cache on link update
Open, NormalPublic

Description

When someone adds or removes a category from a page, the relevant category page changes. And when someone adds or removes an image from a page, the relevant image description page changes, due to the list of file links.

Cache updates for these changes are handled by LinksUpdate::invalidatePages(). However, this function does not update the HTML file cache (i.e. $wgUseFileCache=true), and it does not purge Squid. Thus, anonymous users see the old versions of categories and image description pages after an edit is made.

The fix is made more complicated by the fact that neither of these updates should be done in the same transaction as the main link update. The link update transaction locks a lot of rows, and needs to be closed off as soon as possible.


Version: 1.17.x
Severity: normal

Details

Reference
bz24575

Event Timeline

bzimport raised the priority of this task from to Low.
bzimport set Reference to bz24575.
bzimport added a subscriber: Unknown Object (MLST).

Weren't LinksUpdate done in the DeferredUpdates?

(In reply to comment #1)

Weren't LinksUpdate done in the DeferredUpdates?

No, and it wouldn't help if they were. DeferredUpdates is mostly useless, I've migrated most callers away from it. I don't know why Chad bothered to work on it in 1.19.

info wrote:

I'm running MediaWiki 1.19.0 and I have the exact problem. My main page doesn't change too, but that kinda makes sense because it doesn't get edited, the changes are just made through template rotation.

I'm gonna add a shell script (which deletes the category files and the main page from the file cache) to crontab.

Is anybody aware of a workaround for this? Not even purging pages seems to help. Only fully clearing the cache (through whatever means) makes a difference.

Is there for example any way I can refresh the caches using a cronjob accessing some php page? (Our project is hosted on a shared host so I dont have many possibilities there)

Steinsplitter raised the priority of this task from Low to Normal.May 6 2015, 3:21 PM
Steinsplitter set Security to None.

Could be related but also could be not. Purging category pages did not help in my case, but it is described as a solution in the linked one. I have to clear the entire cache. I am not sure how their configuration would differ from mine to lead to this difference.

This bug seems easier to fix now then when it was originally filed. I think you can just add an onTransactionIdle callback to squid/file cache purge the pages to the callback that's in SqlDataUpdate::invalidatePages

Krinkle renamed this task from Category and image description pages not purged from file cache or squid cache on link update to Purge Category and File description pages from file cache or squid cache on link update.Apr 7 2017, 10:17 PM
Krinkle added a project: Performance-Team.
Krinkle removed a subscriber: wikibugs-l-list.
Gilles moved this task from Inbox to Radar on the Performance-Team board.Apr 12 2017, 7:50 PM
Fenyx4 added a subscriber: Fenyx4.EditedMar 18 2019, 3:33 AM

This bit me too. My categories and images weren't updated for users not logged in. Some of the ones I found that were being effected were over a year old. :(

Jdforrester-WMF added a subscriber: Jdforrester-WMF.

Looks like easy according to T26575#1746030

I think you're radically under-estimating how deeply scary anything related to the Squid/Varnish/ATS CDN caching layer is. This would not remotely be a suitable first bug.