This global is set from /maintenance/runJobs.php and from internal /rpc endpoints, is undocumented, and is non-reliable, as for example it's not set from MediaWiki Special:RunJobs.
There's a few usages of the global.
We're planning to make WMF infrastructure use a REST endpoint for executing the jobs, and setting a global from within a REST handler would be a code smell.
We need to evaluate whether the variable is really needed. If it is, there's some alternative solutions:
- We're planning on making the JobRunner a service and use it everywhere for executing the jobs, so we can add the capability to check whether the service is instantiated (via MediaWikiServices::peekService). The downside is that we're going to be relying on the fact that only job runners ever instantiate a JobRunner. This fact is true and would likely remain true, but nothing really prevents a non-job-runner to require the service by mistake.
- Set flag within the service to indicate whether the execution is currently in the JobRunner context. This will probably not work for deferred updates called from within job execution.
- Set the variable in mw-config depending on whether the execution is happening on jobrunner cluster. This will work for the WMF, but not for other installations, plus I didn't find an elegant way of figuring out which cluster is MW running on
This is an exploratory task and a proposal, keeping the status quo (defining a global) wouldn't be critically horrible either.