The changes of the in-process job execution in MediaWiki 1.22 and 1.23, which basically made job execution asynchronously, is problematic in a not small number of MediaWiki installations out there, as documented in the job queue man page.
We have basically bugs like
- T107290: Run jobs async does not honor $wgServerName
- T68485: runJobs not following redirect
- T68225: Special:RunJobs recursively calling Special:RunJobs again (?)
In MediaWiki 1-27 this seems to be worse, or at least I've noticed a large increase in the number of users reporting issues with this (on installations upgraded from previous versions), where the job queue is not working and there's no error message or anything warning about the complete failure of the jobs. The only visible effect, and totally unrelated to anyone not familiar with the job queue, is that categories aren't being populated.
- Categories not updating
- Category page not updating or created when adding a page to it
- Upgrading from 1.26 to 1.27 breaks putting pages in a category
- Category page does not show links to pages in category
- Categories not working
- Side contents are updating only after edit+save, refresh has no effect
- Jobs are not executed in MediaWiki 1.23.2
- bad URL generating 500 after upgrade
- Jobs won't run, templates not updating.
- T141626: New Articles don't show up in Category in mediawiki 1.27
In all cases, the solution is to turn $wgRunJobsAsync to false. This should be the default value for new installations, and people that wants to increase performance can test if $wgRunJobsAsync works for them and enable it, or better yet, use other options like a cron job or redis. Default Settings should have settings that work in all environments, and that's currently not the case. Since the current asynchronous execution will never work in all scenarios, and nobody is working on a fix, can we just turn that setting off so it just works?