@AGueyte is currently experiencing this problem; @STran has observed something similar in the past, but is not experiencing it any more (I think?). If you have anything helpful to add that I may have missed, please do!

I think this is from T246935: Job queue runners for MediaWiki-Docker, where the jobqueue container is always processing jobs as they're added to the queue. You could verify that by running docker-compose logs -f to see.

If that's the case, one option would be to add a docker-compose.override.yml file (see DEVELOPERS.md in the repo root for more information on that), and you can use the technique described here to prevent the service from starting. Or you might be able to override the entrypoint to do something else like run the true command (or something like that) for the jobqueue service.

Thank you @kostajh. Is the current behaviour desired then - i.e. should we close this task, and maybe update some documentation somewhere instead?

@AGueyte Does T305167#7822992 solve the problem?

In T305167#7832005, @Tchanders wrote:

Thank you @kostajh. Is the current behaviour desired then - i.e. should we close this task, and maybe update some documentation somewhere instead?

@AGueyte Does T305167#7822992 solve the problem?

Hi Thalia and thank you @kostajh for the explanation.
It doesn't make any changes for me!

The $wgJobRunRate configuration variable controls the rate at which jobs are processed during web requests. This is the fallback / last resort manner to run jobs, and is typically what we resort to (automatically) when MediaWiki is used to operate a small small wiki through a stable Debian package, or one-click shared hosting (DirectAdmin, Installatron, etc.), or as developer locally if you manage your own custom web server (e.g. you install your own Apache package, or use the PHP built-in webserver without MySQL/Apache, such as via composer mw-install:sqlite && composer serve).

For all but a single-person wiki, though, we generally recommend that people turn this off (documentation) in favour of a cron job. Even very basic shared web hosts that run MediaWiki, tend to have access to a cron scheduler of sorts to help smoothen this out. E.g. if you have a few extra extensions installed, it's quite possible that one edit will queue multiple jobs, which would then take many (uncached) pageviews to process which is not great. There's also issues with things like template edits or email notifications that are split up into many separate jobs that would make the wiki lag behind for a while.

The MediaWiki-Docker environment tries to approximate a production environment a little bit, which includes using a multi-threaded web server (Apache) that supports "real" deferred updates (not blocking the response), and running jobs continously from a background process rather than only once per page view.

Long story short: $wgJobRunRate = 0; does not make an observable difference for its value is already 0 in the PlatformSettings.php file, which MediaWiki includes from mediawiki-docker loads before the LocalSettings.php file. Similarly, it is also 0 in the Beta Cluster and in production.

To pause the jobrunner in mediawiki-docker specifically, one could do something like:

docker compose pause mediawiki-jobrunner

Followed at some point by docker compose unpause mediawiki-jobrunner, or an overall docker compose restart which will pick it as well. There might also be a button to pause/unpause jobrunner in the Docker Desktop user interface (on macOS and Windows).