Might also belong in ci-test-error and/or Continuous-Integration-Infrastructure, not sure. From a codesearch for getMasterPos(), it seems plausible that this issue could have existed for a while already without being noticed (it seems the method isn’t called very often and some of the places where it is called might not be reached during CI tests).

The reason the CI job fails is the replication rights are not provided. It is a global permission to the database and is not part of the GRANT ALL we do.

The reason it surfaces is the code uses loadBalancer->waitForAll() which is the low level implementation and actually requires those rights. Other methods are smarter and manage to get there are now attached replica to wait for and would return immediately. From maintenance/includes/Maintenance.php which does batch handling as well:

$lbFactory = MediaWikiServices::getInstance()->getDBLoadBalancerFactory();
$lbFactory->waitForReplication();

I have left some hints on the change.

We can check whether we will want Quibble to setup a replication database (and thus start a 2nd database). Though in practice I don't think that has ever been needed/requested.

We can check whether we will want Quibble to setup a replication database (and thus start a 2nd database). Though in practice I don't think that has ever been needed/requested.

I think this would be pretty useful, as I think integration and Selenium tests would end up surfacing some bugs before they hit production. I believe a fair number of developers use only a single database setup in their local environment (e.g. this is the default in the Vagrant setup as well as core's MediaWiki-Docker setup, although it's fairly easy to change to use replication) so it's harder to see issues that can happen when replication is involved.