Hi, please is this issue still open?

If yes can I work on it?

Hi @Destiny, the issue was filed only 2 hours ago, so naturally it is still open. You're welcome to work on it, if you think you can find out why this problem is happening. Note that we probably won't be able to guide you if you get stuck, though.

OK, thanks

Even if you can't fix it, finding reliable steps to make the error appear would be really helpful.

In T371849#10043789, @Bawolff wrote:

Even if you can't fix it, finding reliable steps to make the error appear would be really helpful.

Sure

I have followed the steps above, and so far I have been unable to replicate the issue. Is it possible to know the exact update script that was ran
e.g

php maintenance/run.php update

also what was the database name and database username that was filled when creating the LocalSettings.php file ?
lastly it will also help to know the means of installation, be it with tar ball or gerrit repo, I used that of tar ball for my test so far.

php maintenance/run.php update

Exactly, that is what the task description already says. :)

also what was the database name and database username that was filled when creating the LocalSettings.php file ?

I do not see how or why that is relevant at all for this issue?

lastly it will also help to know the means of installation, be it with tar ball or gerrit repo, I used that of tar ball for my test so far.

No, that is irrelevant here.

Ok, the reason I asked is that after installing the specified version of MediaWiki, mine worked perfectly even after installing oathauth, when I checked MySQL to see if there was any database virtual, there was no such thing, also when creating the LocalSettings.php file some of this information are requested, like the database name and user, by default it uses root, so if the default was left as root it might course the reason of denied permission. So maybe a little context on what the virtual database is about would help. Thanks for your response so far.

Ok, the reason I asked is that after installing the specified version of MediaWiki, mine worked perfectly even after installing oathauth, when I checked MySQL to see if there was any database virtual, there was no such thing, also when creating the LocalSettings.php file some of this information are requested, like the database name and user, by default it uses root, so if the default was left as root it might course the reason of denied permission. So maybe a little context on what the virtual database is about would help. Thanks for your response so far.

The task for this bug is to figure out why the error is happening, what is the cause, and why it is showing up for some people but not others. If we knew what was going on, we wouldn't have this task. If you're new to MW development, this might not be the best task to start out with, because it has already stumped a lot of people, so the answer is probably something unexpected.

lastly it will also help to know the means of installation, be it with tar ball or gerrit repo, I used that of tar ball for my test so far.

No, that is irrelevant here.

There is a small possibility that the cause could be related to users upgrading from a previous version, but not doing the upgrade correctly, resulting in a mix of files from different versions of MediaWiki (e.g. By extracting a tarball over an existing install). The way people talk about this issue makes me think that is not the case, but it hasn't been totally ruled out.

Another potential theory is that somehow the DBLoadBalancerFactoryConfigBuilder service gets constructed prior to all extensions being loaded (thus having the wrong arguments).

For older installs... Is $wgOATHAuthDatabase set, for example? And/or are they seeing '$wgOATHAuthDatabase is deprecated, configure the virtual-oathauth virtual domain instead' deprecation warnings?

As with how it is used, it does override

class MWServicesHandler implements MediaWikiServicesHook {
	/** @inheritDoc */
	public function onMediaWikiServices( $services ) {
		global $wgOATHAuthDatabase, $wgVirtualDomainsMapping;

		if ( $wgOATHAuthDatabase && !isset( $wgVirtualDomainsMapping['virtual-oathauth'] ) ) {
			$wgVirtualDomainsMapping['virtual-oathauth'] = [ 'db' => $wgOATHAuthDatabase ];

			wfDeprecatedMsg(
				'$wgOATHAuthDatabase is deprecated, configure the virtual-oathauth virtual domain instead',
				'1.42',
			);
		}
	}

And/or is that actually being run before UpdateTables::getDatabase() tries to do getPrimaryDatabase( 'virtual-oathauth' )?

The removed comment seems... interesting/telling - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/OATHAuth/+/966600/13/src/Hook/UpdateTables.php#b90

Talking with one of the affected users from discord, I got them to var_dump( \ExtensionRegistry::getInstance()->getAttribute( 'DatabaseVirtualDomains' ) ) at time of making the DB select, and \ExtensionRegistry::getInstance()->getAttribute( 'DatabaseVirtualDomains' ) returned an empty array. Which is kind of weird, it suggests that the issue isn't DB code at all, but extension.json isn't registering the virtual domain

I asked the user to try the command line updater, and it worked, so i guess its specific to web installer. (Its unclear if all the other posts were for the web installer. I assumed they were using command line, but maybe that was a bad assumption by me. I also got the impression that some of them were during normal operation, not update, but maybe i was wrong)

The removed comment seems... interesting/telling - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/OATHAuth/+/966600/13/src/Hook/UpdateTables.php#b90

That does sound suspiciously similar.

I can confirm that I can reproduce this locally on the web updater, with no special configuration other then enabling OATHAuth

The problem is DatabaseUpdater::loadExtensions() does not set Installer::$virtualDomains which is in turn used to construct the loadbalancer during update via installer.

As Denver mentioned in https://www.mediawiki.org/wiki/Topic:Yakailc03f0u43c0 , upgrading a wiki from 1.39.10 to 1.43.0 requires that you add the OATHAuth from 1.41.X to the extension folder, update the database with

$ php maintenance/run.php update.php

Afterwards I ran it again with the OATHauth for 1.43.0 though it did not seem to be required.

The upgrade from 1.39.10 to 1.43.0 DID NOT work for me without this workaround even when I ran the script from the server.

I was getting a similar error when upgrading from 1.40 to 1.43, but with the CLI updater:

Running MediaWiki\Extension\OATHAuth\Maintenance\UpdateForMultipleDevicesSupport...
Wikimedia\Rdbms\DBQueryError from line 1198 of /var/www/mediawiki/includes/libs/rdbms/database/Database.php: Error 1146: Table 'xxxx.oathauth_types' doesn't exist
Function: MediaWiki\Extension\OATHAuth\OATHAuthModuleRegistry::getModuleIdsFromDatabase
Query: SELECT  oat_id,oat_name  FROM `oathauth_types`     

#0 /var/www/mediawiki/includes/libs/rdbms/database/Database.php(1182): Wikimedia\Rdbms\Database->getQueryException()
#1 /var/www/mediawiki/includes/libs/rdbms/database/Database.php(1156): Wikimedia\Rdbms\Database->getQueryExceptionAndLog()
#2 /var/www/mediawiki/includes/libs/rdbms/database/Database.php(647): Wikimedia\Rdbms\Database->reportQueryError()
#3 /var/www/mediawiki/includes/libs/rdbms/database/Database.php(1345): Wikimedia\Rdbms\Database->query()
#4 /var/www/mediawiki/includes/libs/rdbms/database/DBConnRef.php(127): Wikimedia\Rdbms\Database->select()
#5 /var/www/mediawiki/includes/libs/rdbms/database/DBConnRef.php(351): Wikimedia\Rdbms\DBConnRef->__call()
#6 /var/www/mediawiki/includes/libs/rdbms/querybuilder/SelectQueryBuilder.php(744): Wikimedia\Rdbms\DBConnRef->select()
#7 /var/www/mediawiki/extensions/OATHAuth/src/OATHAuthModuleRegistry.php(132): Wikimedia\Rdbms\SelectQueryBuilder->fetchResultSet()
#8 /var/www/mediawiki/extensions/OATHAuth/src/OATHAuthModuleRegistry.php(93): MediaWiki\Extension\OATHAuth\OATHAuthModuleRegistry->getModuleIdsFromDatabase()
#9 /var/www/mediawiki/extensions/OATHAuth/maintenance/UpdateForMultipleDevicesSupport.php(56): MediaWiki\Extension\OATHAuth\OATHAuthModuleRegistry->getModuleIds()
#10 /var/www/mediawiki/maintenance/includes/LoggedUpdateMaintenance.php(51): MediaWiki\Extension\OATHAuth\Maintenance\UpdateForMultipleDevicesSupport->doDBUpdates()
#11 /var/www/mediawiki/includes/installer/DatabaseUpdater.php(1140): MediaWiki\Maintenance\LoggedUpdateMaintenance->execute()
#12 /var/www/mediawiki/includes/installer/DatabaseUpdater.php(595): MediaWiki\Installer\DatabaseUpdater->runMaintenance()
#13 /var/www/mediawiki/includes/installer/DatabaseUpdater.php(552): MediaWiki\Installer\DatabaseUpdater->runUpdates()
#14 /var/www/mediawiki/maintenance/update.php(195): MediaWiki\Installer\DatabaseUpdater->doUpdates()
#15 /var/www/mediawiki/maintenance/includes/MaintenanceRunner.php(703): UpdateMediaWiki->execute()
#16 /var/www/mediawiki/maintenance/run.php(51): MediaWiki\Maintenance\MaintenanceRunner->run()
#17 /var/www/mediawiki/maintenance/run(3): require('...')
#18 {main}

The workaround of upgrading first to 1.41 seems to work fine and the oathauth_types and oathauth_devices tables are created.

Today is the last day before the train rides for 1.44.0-wmf.28 [1] and the alpha branch release [2] will soon be announced.

I'm flagging this task as a non-blocker, but if that's not right, please make sure this is resolved and backported before the release is complete in a few weeks.

https://www.mediawiki.org/wiki/MediaWiki_1.44/wmf.28
https://www.mediawiki.org/wiki/MediaWiki_1.44/Roadmap

Not to be a dick but it is claimed that updating from two versions ago is supported by the team but this is still not working after over half a year.

Of course updating Oauth to the 1.41.x version before updating it to the 1.43.x version was enough to update my four wikis, but I don’t think this should be required.

This could easily screw someone over who updates their wiki without proper safeguards in place.

If anyone updates from 1.39.x to 1.44 they get a broken wiki unless they find out about this bug in the oauth extension and how to fix it.

Given the 'High' priority set in T371849#10715418, I'm gonna boldly tag MediaWiki-Platform-Team as the extension steward for OATHAuth listed at https://mediawiki.org/wiki/Developers/Maintainers, for them to have a look at.
(side note, should this have happened automatically through H425 / H428?)

(side note, should this have happened automatically through H425 / H428?)

No, for some projects H428 only triggers when the project is added to a new task, not when an existing task with the project is bumped. H425 triggers always but only includes a different list of projects and OAuth is an H428 project. Why they set it up this way is unclear, but it's working as intended.

OATHAuth doesn't appear to be on either of them, though - I'm wondering if that was an unintentional oversight

Oh, whoops, I conflated OATH and OAuth.