Topic on Project:Support desk/Flow

I'm updating from 1.25 to 1.27.1 and I have major problems with the cache.

E.g. file usage doesn't update. I add an image to another page, but the file usage on the image page only lists the old page.

I remove a category from the image, but the category page still lists it.

Or page info: I watch a page but the number of wathcing users is still 0.

Didn't help:

• action=purge
• Refreshing $wgCacheEpoch

Setup:

• MW 1.27.1
• PHP 5.5.9-1ubuntu4.14 (apache2handler)
• PHP Opcache
• $wgMainCacheType = $wgParserCacheType = $wgMessageCacheType = $wgSessionCacheType = CACHE_MEMCACHED;
• $wgUseFileCache = true;

See Manual:$wgRunJobsAsync! Also note that there will be additional changes to the job queue in MW 1.27.2 - the story of bugs will continue! ;-(

Ah f**k, thanks. I remember reading about here days ago. Yes, MW gets worse and worse. It started when they removed the hitcounter...

Now with $wgJobRunRate = 3; and $wgRunJobsAsync = false; the cat changes appeared after a few clicks (~20 sec).

I added an image to a cat. After browsing some pages I now see the new categorization, but only with action=purge. But normal users don't use that. They think the wiki is broken :(

Even if I runJobs.php as a non stop cron job: What if the job queue is filled with slow entries like thumbs or 10k jobs for Extension:ReplaceText? The contributor will see cat changes only after minutes?

So I need a live job queue and action=purge to see changes? WTF! This is big time crap. Sorry for the harsh words.

Test on mediawiki.org: A categorized image appeared after 20 seconds and without action=purge. Hmh.

Btw: The "Number of page watchers" on action=info does not update at all.

After minutes is better than not at all, right? You do not need action=purge, it just makes this one update faster. And btw only updating a page itself, has nothing to do with the job queue...

It was the browser cache. That makes it even worse.

• Go to Category:Foo, delete a page
• Go back to the cat page
• Wait till the job is done
• Reload > Red link
• action=purge > Link gone
• Click the category tab (no purge) > Red link

Shouldn't the page invalidate after the job is done? I hadn't such problems on MW 1.25 where I use the same headers.

This is cache hell!!!

I wasted 3 days updating MediaWiki and now this shit :(

Ok, it's not the browser cache. I remembered, on cat pages I return a list of pages in a custom ns. Its cache is flushed on the edit complete hook for the page's belonging categories.

This is gone in the wind now when the user visist a page's new categorized cat page before the job updated it.

I need a hook then for JobCompleteAfterCategorization... lol :(

I know reloading doesn't push the job queue. Tell that my contributors... They categorize an image, click on the cat link and don't find that image.

I added a purge tab on top for general cache reloading. It now doesn't fix this.

So users now need to understand browser cache, server cache and "unchanged edits"?

All this is waaaay too confusing.

And again: What if the queue is full with slow jobs and thousands of batch / bot edits?

Do these new cache jobs have a specific type so I can run these as non stop cron job?

I could exclude slow jobs via $wgJobTypesExcludedFromDefaultQueue ...

Being a MediaWiki admin is hard ;)

Won't help either. The non-stop cronjob checks if "runJobs.php" is running... MEH!

The job queue is broken. Maybe because it got implemented badly, maybe because it has basical flaws, which are hard or even impossible to fix. I don't know that.

All I know is that the job queue in many cases and for many users is not working as expected. Setting up a cron job can help, also to get ReplaceText rows done.

The real solution is to nudge the developers to get the basic system functional - and then to configure it properly.

Bug report: https://phabricator.wikimedia.org/T145206