MediaWiki version: 1.36.0-wmf.1
Class 'MediaWiki\Installer\Services\InstallerDBSupport' not found
There were at least 16000 of these around 2020-07-23T00:16:52, but none since. Looks like a programming error to me, though. Presumably not an ongoing problem right now, but might happen again.
#0 /srv/mediawiki/php-1.36.0-wmf.1/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1242): Wikimedia\Rdbms\Database::attributesFromType(string, NULL)
#1 /srv/mediawiki/php-1.36.0-wmf.1/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1284): Wikimedia\Rdbms\LoadBalancer->getServerAttributes(integer)
#2 /srv/mediawiki/php-1.36.0-wmf.1/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1096): Wikimedia\Rdbms\LoadBalancer->reallyOpenConnection(integer, Wikimedia\Rdbms\DatabaseDomain, array)
#3 /srv/mediawiki/php-1.36.0-wmf.1/includes/libs/rdbms/loadbalancer/LoadBalancer.php(929): Wikimedia\Rdbms\LoadBalancer->getLocalConnection(integer, integer)
#4 /srv/mediawiki/php-1.36.0-wmf.1/includes/libs/rdbms/loadbalancer/LoadBalancer.php(633): Wikimedia\Rdbms\LoadBalancer->getServerConnection(integer, string, integer)
#5 /srv/mediawiki/php-1.36.0-wmf.1/includes/libs/rdbms/loadbalancer/LoadBalancer.php(527): Wikimedia\Rdbms\LoadBalancer->pickReaderIndex(array, string)
#6 /srv/mediawiki/php-1.36.0-wmf.1/includes/libs/rdbms/loadbalancer/LoadBalancer.php(479): Wikimedia\Rdbms\LoadBalancer->getReaderIndex(string, string)
#7 /srv/mediawiki/php-1.36.0-wmf.1/includes/libs/rdbms/loadbalancer/LoadBalancer.php(899): Wikimedia\Rdbms\LoadBalancer->getConnectionIndex(integer, array, string)
#8 /srv/mediawiki/php-1.36.0-wmf.1/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1046): Wikimedia\Rdbms\LoadBalancer->getConnection(integer, array, string, integer)
#9 /srv/mediawiki/php-1.36.0-wmf.1/includes/GlobalFunctions.php(2468): Wikimedia\Rdbms\LoadBalancer->getMaintenanceConnectionRef(integer, array, string)
#10 /srv/mediawiki/php-1.36.0-wmf.1/includes/block/DatabaseBlock.php(258): wfGetDB(integer)
#11 /srv/mediawiki/php-1.36.0-wmf.1/includes/block/DatabaseBlock.php(1187): MediaWiki\Block\DatabaseBlock::newLoad(User, integer, boolean, string)
#12 /srv/mediawiki/php-1.36.0-wmf.1/includes/block/BlockManager.php(139): MediaWiki\Block\DatabaseBlock::newListFromTarget(User, string, boolean)
#13 /srv/mediawiki/php-1.36.0-wmf.1/includes/user/User.php(1604): MediaWiki\Block\BlockManager->getUserBlock(User, WebRequest, boolean)
#14 /srv/mediawiki/php-1.36.0-wmf.1/includes/user/User.php(1896): User->getBlockedStatus(boolean)
#15 /srv/mediawiki/php-1.36.0-wmf.1/includes/block/BlockManager.php(472): User->getBlock()
#16 /srv/mediawiki/php-1.36.0-wmf.1/includes/MediaWiki.php(767): MediaWiki\Block\BlockManager->trackBlockWithCookie(User, WebResponse)
#17 /srv/mediawiki/php-1.36.0-wmf.1/includes/api/ApiMain.php(555): MediaWiki::preOutputCommit(DerivativeContext)
#18 /srv/mediawiki/php-1.36.0-wmf.1/includes/api/ApiMain.php(500): ApiMain->executeActionWithErrorHandling()
#19 /srv/mediawiki/php-1.36.0-wmf.1/api.php(90): ApiMain->execute()
#20 /srv/mediawiki/php-1.36.0-wmf.1/api.php(45): wfApiMain()
#21 /srv/mediawiki/w/api.php(3): require(string)
#22 {main}I'm not sure. @Legoktm should know for sure.
Looking at the code; the stack points at Database::attributesFromType, a path touched in the revert. Given that it threw a class not found error, I suspect that the request was made after the InstallerDBSupport class was removed, but before the Database class was changed if my understanding of how Scap works is correct.
Based on that conclusion, I would wager that when group 2 is promoted to 1.36-wmf.1, these errors might pop up temporarily again.
@Legoktm said on IRC it was his mistake in how the revert was rolled out, so not a bug in the code as such.
I'll leave the task open in case something happens when train reaches group2, to make it easier to find.
Yeah. I tried syncing all of includes/ so in some cases the InstallerDBSupport class was removed before the Database class was updated causing temporary fatals. I'm more rusty than I thought when it comes to deployments... I did it correctly for wmf.43, where I synced Database.php before includes/.
Based on that conclusion, I would wager that when group 2 is promoted to 1.36-wmf.1, these errors might pop up temporarily again.
Train deploys don't suffer from this problem because all of the files are already in place and staged and then a single change to wikiversions switches which code is loaded.
Worth keeping open for a deployer education reminder to not do this? Or just close as Invalid?