T63387 Provide a way to revert to the old on-request job queue handling (original) (raw)
Provide a way to revert to the old on-request job queue handling
- Edit Task
- Edit Related Tasks...
- Create Subtask
- Edit Parent Tasks
- Edit Subtasks
- Merge Duplicates In
- Close As Duplicate
- Edit Related Objects...
- Edit Commits
- Edit Mocks
- Mute Notifications
- Protect as security issue
Since the various changes [1] introduced in the Job Queue handling during normal page requests, it caused a lot of problems [2] on installations where the on-request job queue is being used (not on WMF wikis, of course, that's why it went unnoticed until 1.22 was released).
The old way of handling the job queue is still present, and will be used if wgPhpCliisnotsettoanactualpath,orsafemodeison.Butstill,there′snootherwayforwikistoreverttotheoldwayunlesssettingwgPhpCli is not set to an actual path, or safe mode is on. But still, there's no other way for wikis to revert to the old way unless setting wgPhpCliisnotsettoanactualpath,orsafemodeison.Butstill,there′snootherwayforwikistoreverttotheoldwayunlesssettingwgPhpCli to false or an empty string, which may be used for something else and cause other undesired side-effects.
We should introduce a configuration setting (for example, wgUseOldOnRequestJobQueueHandling=true)torevertthejobqueuehandlingwithoutinterferingwithwgUseOldOnRequestJobQueueHandling = true) to revert the job queue handling without interfering with wgUseOldOnRequestJobQueueHandling=true)torevertthejobqueuehandlingwithoutinterferingwithwgPhpCli, which should default to the old job queue handling, until those issues are fixed, while letting developers and experienced sysadmins enable this *experimental* (at best) feature.
[1] https://www.mediawiki.org/wiki/Manual:Job_queue#Changes_introduced_in_MediaWiki_1.22
Version: 1.22.0
Severity: normal
Event Timeline
(In reply to Andre Klapper from comment #1)
What is the difference towards fixing bug 46934?
bug 46934 may or may not describe one of the problems already identified in [1].
This bug is to introduce a wgvariabletoprovideawaytoreverttotheoldwayofrunningjobsfromthequeueonpagerequests,andnothavingtosetwg variable to provide a way to revert to the old way of running jobs from the queue on page requests, and not having to set wgvariabletoprovideawaytoreverttotheoldwayofrunningjobsfromthequeueonpagerequests,andnothavingtosetwgPhpCli to false, pontentially breaking something else.
Note that the problems with the new job queue handling were introduced in 1.22 (that's why Priority was set to High), while bug 46934 is marked as affecting 1.21, so it may have nothing to do with this one.
[1] https://www.mediawiki.org/wiki/Manual:Job_queue#Changes_introduced_in_MediaWiki_1.22
This feature should be called "experimental", or "beta", and be able to fall back to the old one easily, for at least one major version, until we're sure it doesn't break havoc as the 1.22 does. This feature isn't extensively tested until it's released on a major version, because WMF wikis don't use it, and we probably want to support those third party users out there rather than offering them a broken product.
Sorry to disagree with you about the priority, but those new changes introduce new problems and now it's even difficult to revert to the old queue.
For 1.22 one could set $wgPhpCli to false (while potentially breaking other things, although on 1.22 there seems to be no other functionality using that variable). But for 1.23 there's no way to disable this behavior
Also, this is easy, since it only needs wrap the code inside
if ($wgNewVariable) { ... }
and add a "else" with the old code.
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits