Page MenuHomePhabricator

PHPUnit failure in various extensions: Wikimedia\Rdbms\DBConnectionError: Cannot access the database: Access denied for user 'wikiuser'@'localhost' to database 'centralauth'
Closed, ResolvedPublicBUG REPORT

Description

List of steps to reproduce (step by step, including full links if applicable):

What happens?:
Test fails with the following message

00:04:23.444    │ Failed asserting that exception of type "Wikimedia\Rdbms\DBConnectionError" matches expected exception "ApiUsageException". Message was: "Cannot access the database: Access denied for user 'wikiuser'@'localhost' to database 'centralauth' (localhost:/workspace/db/quibble-mysql-w8t98ib0/socket)" at

Stack trace:

Wikibase\Client\Tests\Unit\Api\ApiFormatReferenceTest
11:30:30  ✘ testInvalidReferenceJson
11:30:30    │
11:30:30    │ Failed asserting that exception of type "Wikimedia\Rdbms\DBConnectionError" matches expected exception "ApiUsageException". Message was: "Cannot access the database: Access denied for user 'wikiuser'@'localhost' to database 'centralauth' (localhost:/workspace/db/quibble-mysql-0qcjx7do/socket)" at
11:30:30    │ /workspace/src/includes/libs/rdbms/loadbalancer/LoadBalancer.php:1465
11:30:30    │ /workspace/src/includes/libs/rdbms/loadbalancer/LoadBalancer.php:958
11:30:30    │ /workspace/src/includes/libs/rdbms/loadbalancer/LoadBalancer.php:931
11:30:30    │ /workspace/src/includes/libs/rdbms/database/DBConnRef.php:65
11:30:30    │ /workspace/src/includes/libs/rdbms/database/DBConnRef.php:649
11:30:30    │ /workspace/src/includes/libs/rdbms/database/Database.php:4281
11:30:30    │ /workspace/src/extensions/CentralAuth/includes/User/CentralAuthUser.php:640
11:30:30    │ /workspace/src/includes/libs/objectcache/wancache/WANObjectCache.php:1692
11:30:30    │ /workspace/src/includes/libs/objectcache/wancache/WANObjectCache.php:1520
11:30:30    │ /workspace/src/extensions/CentralAuth/includes/User/CentralAuthUser.php:660
11:30:30    │ /workspace/src/extensions/CentralAuth/includes/User/CentralAuthUser.php:465
11:30:30    │ /workspace/src/extensions/CentralAuth/includes/User/CentralAuthUser.php:714
11:30:30    │ /workspace/src/extensions/CentralAuth/includes/User/CentralAuthUser.php:807
11:30:30    │ /workspace/src/extensions/CentralAuth/includes/CentralAuthHooks.php:568
11:30:30    │ /workspace/src/includes/HookContainer/HookContainer.php:160
11:30:30    │ /workspace/src/includes/HookContainer/HookRunner.php:1942
11:30:30    │ /workspace/src/includes/block/BlockManager.php:179
11:30:30    │ /workspace/src/includes/user/User.php:1436
11:30:30    │ /workspace/src/includes/user/User.php:1752
11:30:30    │ /workspace/src/includes/api/ApiBase.php:1285
11:30:30    │ /workspace/src/includes/api/ApiBase.php:1528
11:30:30    │ /workspace/src/extensions/Wikibase/client/includes/Api/ApiFormatReference.php:56
11:30:30    │ /workspace/src/extensions/Wikibase/client/tests/phpunit/unit/includes/Api/ApiFormatReferenceTest.php:141
11:30:30    │ phpvfscomposer:///workspace/src/vendor/phpunit/phpunit/phpunit:97
11:30:30    │ .
11:30:30    │
11:30:30    │ phpvfscomposer:///workspace/src/vendor/phpunit/phpunit/phpunit:97

What should have happened instead?:

The test should not fail

Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.:
Current Jenkins config

Event Timeline

Could be related to T90875?

It's possible, but I am not sure why it didn't fail earlier.

kostajh renamed this task from Math CI tests fail to Wikibase\Client\Tests\Unit\Api\ApiFormatReferenceTest#testInvalidReferenceJson failure.Jun 9 2022, 10:25 AM
kostajh updated the task description. (Show Details)

Change 804279 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/Wikibase@master] ApiFormatReferenceTest: Temporarily disable testInvalidReferenceJson

https://gerrit.wikimedia.org/r/804279

I can’t reproduce this yet, vendor/bin/phpunit extensions/Wikibase/client/tests/phpunit/unit/ works fine for me with latest MediaWiki core and Wikibase…

Edit: D’oh, that would be because I don’t have CentralAuth installed. I’ll look into that a bit more.

Okay, I can reproduce the error with wfLoadExtension( 'CentralAuth' ); in LocalSettings.

If I add $wgCentralAuthDatabase = $wgDBname;, then the error message changes:

Failed asserting that exception of type "Wikimedia\Rdbms\DBQueryError" matches expected exception "ApiUsageException". Message was: "Error 1146: Table 'wiki1.globaluser' doesn't exist

(wiki1 is my DB name.) And when I then run php maintenance/mysql.php < extensions/CentralAuth/schema/mysql/tables-generated.sql, then the tests pass:

$ vendor/bin/phpunit extensions/Wikibase/client/tests/phpunit/unit/includes/Api/ApiFormatReferenceTest.php 
Using PHP 8.1.2
PHPUnit 8.5.26 #StandWithUkraine

Wikibase\Client\Tests\Unit\Api\ApiFormatReferenceTest
 ✔ testAsDataBridgeForHtml
 ✔ testInvalidReferenceJson
 ✔ testInvalidReferenceSerialization

Time: 430 ms, Memory: 52.50 MB

OK (3 tests, 8 assertions)

So it’s something about the way CentralAuth is set up that previously used to work in CI but now doesn’t.

Okay, CentralAuth sets up its database in UnitTestsHookHandler::onUnitTestsAfterDatabaseSetup(), but that hook is only run by MediaWikiIntegrationTestCase::setupTestDB(). ApiFormatReferenceTest and QuerySearchEntitiesTest are nominally unit tests, not integration tests, so the database doesn’t get set up, but then CentralAuth still runs as if it’s in an integration test.

I think the correct solution here is to declare those tests as integration tests. Trying to run a whole API module as only a unit test feels like a fool’s errand to me, at least at the moment. Perhaps a few years down the line, MediaWiki will be disciplined enough about dependency injection that API modules won’t interact with global state or the real wiki configuration, but until then, this should have its own database.

But this also highlights something that was brought up in the Gerrit discussion:

Per Kosta on IRC, there's a chance the speed up is itself suspicious and possibly indicating we missed something, e.g. some kind of protection layer or reset.

I think that’s exactly what’s happening – these unit tests, and presumably many others like them, previously enjoyed the protection layer of having a separate database set up for them, and now they don’t. I think we’re now running anything that claims to be a unit test against the real database of the wiki, and if it happens to hit a code path that isn’t ready for unit tests, so to speak (like this CentralAuth hook), then who knows what happens. IMHO this needs to be fixed in MediaWiki core – I don’t think it was sufficiently communicated that all extension unit tests would now be less “sandboxed”, so to speak.

Change 804279 abandoned by Kosta Harlan:

[mediawiki/extensions/Wikibase@master] ApiFormatReferenceTest: Temporarily disable testInvalidReferenceJson

Reason:

https://gerrit.wikimedia.org/r/804279

Okay, CentralAuth sets up its database in UnitTestsHookHandler::onUnitTestsAfterDatabaseSetup(), but that hook is only run by MediaWikiIntegrationTestCase::setupTestDB(). ApiFormatReferenceTest and QuerySearchEntitiesTest are nominally unit tests, not integration tests, so the database doesn’t get set up, but then CentralAuth still runs as if it’s in an integration test.

I think the correct solution here is to declare those tests as integration tests.

+1, that makes sense to me.

As for the general problem about separate unit/integration runs, composer phpunit:unit runs which uses a fairly restrictive bootstrap file. Any attempts to access the database there or MediaWiki services would fail, for example. That command looks for tests that are in the tests/phpunit/unit subdirectory.

So, we need to update Quibble's PHPUnit commands to then ensure that tests/phpunit/unit is excluded from integration test runs. We could do that by applying @group Unit to each unit test class and then using --exclude Unit in Quibble. That's a lot of work, though. We could also have ExtensionTestSuite manually exclude any tests that are in tests/phpunit/unit subdirectory, but that wouldn't handle the test run that happens for core. Maybe it is most straightforward (but also another hack) to just remove the tests/phpunit/unit directory from each project after composer phpunit:unit runs.

Change 804283 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] Change API tests from unit tests to integration tests

https://gerrit.wikimedia.org/r/804283

I think we’re now running anything that claims to be a unit test against the real database of the wiki

Confirmed:

tests/phpunit/unit/includes/LucasTest.php
<?php

class LucasTest extends \PHPUnit\Framework\TestCase {

	public function testDatabaseAccess(): void {
		var_dump( wfGetDB( DB_PRIMARY )->selectRow(
			'recentchanges',
			[ 'rc_title', 'rc_timestamp' ],
			'',
			__METHOD__,
			[
				'LIMIT' => 1,
				'ORDER BY' => 'rc_timestamp DESC',
			]
		) );
	}

}
$ vendor/bin/phpunit tests/phpunit/unit/includes/LucasTest.php
Using PHP 8.1.2
PHPUnit 8.5.26 #StandWithUkraine

LucasTest
 ☢ testDatabaseAccess
/var/www/html/wiki1/tests/phpunit/unit/includes/LucasTest.php:12:
class stdClass#876 (2) {
  public $rc_title =>
  string(21) "Page_with_1000_commas"
  public $rc_timestamp =>
  string(14) "20220604150204"
}

“Page with 1000 commas” is indeed the latest recentchanges entry on my local wiki, from 2022-06-04. This test is accessing the real wiki database. In my opinion, this should never happen – integration tests should have the test DB, and for unit tests, database access should fail.

Prior to 7238dff532, that test produces the following error:

Premature access to service container [Called from wfGetDB in /var/www/html/wiki1/includes/GlobalFunctions.php at line 1945]

/var/www/html/wiki1/includes/debug/MWDebug.php:381
/var/www/html/wiki1/includes/debug/MWDebug.php:352
/var/www/html/wiki1/includes/GlobalFunctions.php:795
/var/www/html/wiki1/includes/MediaWikiServices.php:278
/var/www/html/wiki1/includes/GlobalFunctions.php:1945
/var/www/html/wiki1/tests/phpunit/unit/includes/LucasTest.php:6

Change 804283 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] Change API tests from unit tests to integration tests

https://gerrit.wikimedia.org/r/804283

Ugh, this doesn’t work yet because there’s one more warning (and those also make gate-and-submit fail):

PHPUnit\Framework\WarningTestCase
 ⚠ Warning
   │
   │ The data provider specified for ApiStructureTest::testParameters is invalid.
   │ Wikimedia\Rdbms\DBConnectionError: Cannot access the database: Access denied for user 'wikiuser'@'localhost' to database 'centralauth' (localhost:/workspace/db/quibble-mysql-wc4x6073/socket)
   │ /workspace/src/includes/libs/rdbms/loadbalancer/LoadBalancer.php:1465
   │ /workspace/src/includes/libs/rdbms/loadbalancer/LoadBalancer.php:958
   │ /workspace/src/includes/libs/rdbms/loadbalancer/LoadBalancer.php:931
   │ /workspace/src/includes/libs/rdbms/database/DBConnRef.php:65
   │ /workspace/src/includes/libs/rdbms/database/DBConnRef.php:270
   │ /workspace/src/extensions/CentralAuth/includes/GlobalGroup/GlobalGroupLookup.php:56
   │ /workspace/src/extensions/CentralAuth/includes/Api/ApiQueryGlobalAllUsers.php:273
   │ /workspace/src/includes/api/ApiBase.php:1782
   │ /workspace/src/tests/phpunit/structure/ApiStructureTest.php:175
   │ phpvfscomposer:///workspace/src/vendor/phpunit/phpunit/phpunit:97

This is a unit test in core… should it also be an integration test? It tests that the parameter definitions of API modules are valid, and in CentralAuth that requires accessing the database so that the defined groups can be used for the group and excludegroup params. (Presumably, other APIs do something similar for tags parameters, that just doesn’t produce an error because the change_tag_def table would exist in the real wiki.)

Wait, no. ApiStructureTest isn’t a unit test, it’s an integration test already, both by location (tests/phpunit/structure/) and type (extends MediaWikiIntegrationTestCase).

But I guess the data providers are evaluated before the onUnitTestsAfterDatabaseSetup() hook runs 😖

I’m actually not sure how this would’ve worked before.

We also observed the ApiStructureTest failure for ContentTranslation.

Wait, no. ApiStructureTest isn’t a unit test, it’s an integration test already, both by location (tests/phpunit/structure/) and type (extends MediaWikiIntegrationTestCase).

But I guess the data providers are evaluated before the onUnitTestsAfterDatabaseSetup() hook runs 😖

I’m actually not sure how this would’ve worked before.

Something I observed before the vendor/bin/phpunit switch is that data providers with exceptions would silently fail, and thus the test wouldn't run at all. But that doesn't seem to be the case here.

I think we’re now running anything that claims to be a unit test against the real database of the wiki

Confirmed:

tests/phpunit/unit/includes/LucasTest.php
<?php

class LucasTest extends \PHPUnit\Framework\TestCase {

	public function testDatabaseAccess(): void {
		var_dump( wfGetDB( DB_PRIMARY )->selectRow(
			'recentchanges',
			[ 'rc_title', 'rc_timestamp' ],
			'',
			__METHOD__,
			[
				'LIMIT' => 1,
				'ORDER BY' => 'rc_timestamp DESC',
			]
		) );
	}

}
$ vendor/bin/phpunit tests/phpunit/unit/includes/LucasTest.php
Using PHP 8.1.2
PHPUnit 8.5.26 #StandWithUkraine

LucasTest
 ☢ testDatabaseAccess
/var/www/html/wiki1/tests/phpunit/unit/includes/LucasTest.php:12:
class stdClass#876 (2) {
  public $rc_title =>
  string(21) "Page_with_1000_commas"
  public $rc_timestamp =>
  string(14) "20220604150204"
}

“Page with 1000 commas” is indeed the latest recentchanges entry on my local wiki, from 2022-06-04. This test is accessing the real wiki database. In my opinion, this should never happen – integration tests should have the test DB, and for unit tests, database access should fail.

Unit (as opposed to integration) tests need to run with a separate bootstrap file. Can you test with vendor/bin/phunit --bootstrap tests/phpunit/bootstrap.php tests/phpunit/unit/includes/LucasTest.php ? That is what composer phpunit:unit is using.

Wait, no. ApiStructureTest isn’t a unit test, it’s an integration test already, both by location (tests/phpunit/structure/) and type (extends MediaWikiIntegrationTestCase).

But I guess the data providers are evaluated before the onUnitTestsAfterDatabaseSetup() hook runs 😖

I’m actually not sure how this would’ve worked before.

Something I observed before the vendor/bin/phpunit switch is that data providers with exceptions would silently fail, and thus the test wouldn't run at all. But that doesn't seem to be the case here.

I think we’re now running anything that claims to be a unit test against the real database of the wiki

Confirmed:

tests/phpunit/unit/includes/LucasTest.php
<?php

class LucasTest extends \PHPUnit\Framework\TestCase {

	public function testDatabaseAccess(): void {
		var_dump( wfGetDB( DB_PRIMARY )->selectRow(
			'recentchanges',
			[ 'rc_title', 'rc_timestamp' ],
			'',
			__METHOD__,
			[
				'LIMIT' => 1,
				'ORDER BY' => 'rc_timestamp DESC',
			]
		) );
	}

}
$ vendor/bin/phpunit tests/phpunit/unit/includes/LucasTest.php
Using PHP 8.1.2
PHPUnit 8.5.26 #StandWithUkraine

LucasTest
 ☢ testDatabaseAccess
/var/www/html/wiki1/tests/phpunit/unit/includes/LucasTest.php:12:
class stdClass#876 (2) {
  public $rc_title =>
  string(21) "Page_with_1000_commas"
  public $rc_timestamp =>
  string(14) "20220604150204"
}

“Page with 1000 commas” is indeed the latest recentchanges entry on my local wiki, from 2022-06-04. This test is accessing the real wiki database. In my opinion, this should never happen – integration tests should have the test DB, and for unit tests, database access should fail.

Unit (as opposed to integration) tests need to run with a separate bootstrap file. Can you test with vendor/bin/phunit --bootstrap tests/phpunit/bootstrap.php tests/phpunit/unit/includes/LucasTest.php ? That is what composer phpunit:unit is using.

@Lucas_Werkmeister_WMDE there's another test to fix as well, see https://integration.wikimedia.org/ci/job/wikibase-client-docker/28093/console:

13:03:46 INFO:quibble.commands:php tests/phpunit/phpunit.php --verbose --log-junit "$LOG_DIR/junit-wikibase-client.xml" --group Wikibase,WikibaseClient
13:03:46 Using PHP 7.3.33-1+0~20211119.91+debian10~1.gbp618351
13:03:46 PHP Deprecated:  tests/phpunit/phpunit.php is deprecated and will be removed. Please use `composer phpunit` or `vendor/bin/phpunit` [Called from unknown in /workspace/src/tests/phpunit/phpunit.php at line 75] in /workspace/src/includes/debug/MWDebug.php on line 381
13:03:46 Deprecated: tests/phpunit/phpunit.php is deprecated and will be removed. Please use `composer phpunit` or `vendor/bin/phpunit` [Called from unknown in /workspace/src/tests/phpunit/phpunit.php at line 75] in /workspace/src/includes/debug/MWDebug.php on line 381
13:03:48 [e70351983cbb3759ca54c6bb] [no req]   Exception: entitySources must be configured for non-repo client wikis
13:03:48 Backtrace:
13:03:48 from /workspace/src/extensions/Wikibase/client/config/WikibaseClient.default.php(211)
13:03:48 #0 /workspace/src/extensions/Wikibase/lib/includes/SettingsArray.php(68): Wikibase\Lib\WikibaseSettings::{closure}(Wikibase\Lib\SettingsArray)
13:03:48 #1 /workspace/src/extensions/Wikibase/client/WikibaseClient.ServiceWiring.php(433): Wikibase\Lib\SettingsArray->getSetting(string)
13:03:48 #2 /workspace/src/vendor/wikimedia/services/src/ServiceContainer.php(447): Wikimedia\Services\ServiceContainer->{closure}(MediaWiki\MediaWikiServices)
13:03:48 #3 /workspace/src/vendor/wikimedia/services/src/ServiceContainer.php(416): Wikimedia\Services\ServiceContainer->createService(string)
13:03:48 #4 /workspace/src/includes/MediaWikiServices.php(295): Wikimedia\Services\ServiceContainer->getService(string)
13:03:48 #5 /workspace/src/vendor/wikimedia/services/src/ServiceContainer.php(424): MediaWiki\MediaWikiServices->getService(string)
13:03:48 #6 /workspace/src/extensions/Wikibase/client/includes/WikibaseClient.php(123): Wikimedia\Services\ServiceContainer->get(string)
13:03:48 #7 /workspace/src/extensions/Wikibase/client/WikibaseClient.ServiceWiring.php(1056): Wikibase\Client\WikibaseClient::getEntitySourceDefinitions(MediaWiki\MediaWikiServices)
13:03:48 #8 /workspace/src/vendor/wikimedia/services/src/ServiceContainer.php(447): Wikimedia\Services\ServiceContainer->{closure}(MediaWiki\MediaWikiServices)
13:03:48 #9 /workspace/src/vendor/wikimedia/services/src/ServiceContainer.php(416): Wikimedia\Services\ServiceContainer->createService(string)
13:03:48 #10 /workspace/src/includes/MediaWikiServices.php(295): Wikimedia\Services\ServiceContainer->getService(string)
13:03:48 #11 /workspace/src/vendor/wikimedia/services/src/ServiceContainer.php(424): MediaWiki\MediaWikiServices->getService(string)
13:03:48 #12 /workspace/src/extensions/Wikibase/client/includes/WikibaseClient.php(160): Wikimedia\Services\ServiceContainer->get(string)
13:03:48 #13 /workspace/src/extensions/Wikibase/client/WikibaseClient.ServiceWiring.php(956): Wikibase\Client\WikibaseClient::getWikibaseServices(MediaWiki\MediaWikiServices)
13:03:48 #14 /workspace/src/vendor/wikimedia/services/src/ServiceContainer.php(447): Wikimedia\Services\ServiceContainer->{closure}(MediaWiki\MediaWikiServices)
13:03:48 #15 /workspace/src/vendor/wikimedia/services/src/ServiceContainer.php(416): Wikimedia\Services\ServiceContainer->createService(string)
13:03:48 #16 /workspace/src/includes/MediaWikiServices.php(295): Wikimedia\Services\ServiceContainer->getService(string)
13:03:48 #17 /workspace/src/vendor/wikimedia/services/src/ServiceContainer.php(424): MediaWiki\MediaWikiServices->getService(string)
13:03:48 #18 /workspace/src/extensions/Wikibase/client/includes/WikibaseClient.php(222): Wikimedia\Services\ServiceContainer->get(string)
13:03:48 #19 /workspace/src/extensions/Wikibase/client/WikibaseClient.ServiceWiring.php(401): Wikibase\Client\WikibaseClient::getStore(MediaWiki\MediaWikiServices)
13:03:48 #20 /workspace/src/vendor/wikimedia/services/src/ServiceContainer.php(447): Wikimedia\Services\ServiceContainer->{closure}(MediaWiki\MediaWikiServices)
13:03:48 #21 /workspace/src/vendor/wikimedia/services/src/ServiceContainer.php(416): Wikimedia\Services\ServiceContainer->createService(string)
13:03:48 #22 /workspace/src/includes/MediaWikiServices.php(295): Wikimedia\Services\ServiceContainer->getService(string)
13:03:48 #23 /workspace/src/vendor/wikimedia/services/src/ServiceContainer.php(424): MediaWiki\MediaWikiServices->getService(string)
13:03:48 #24 /workspace/src/extensions/Wikibase/client/includes/WikibaseClient.php(170): Wikimedia\Services\ServiceContainer->get(string)
13:03:48 #25 /workspace/src/extensions/Wikibase/client/WikibaseClient.ServiceWiring.php(826): Wikibase\Client\WikibaseClient::getEntityLookup(MediaWiki\MediaWikiServices)
13:03:48 #26 /workspace/src/vendor/wikimedia/services/src/ServiceContainer.php(447): Wikimedia\Services\ServiceContainer->{closure}(MediaWiki\MediaWikiServices)
13:03:48 #27 /workspace/src/vendor/wikimedia/services/src/ServiceContainer.php(416): Wikimedia\Services\ServiceContainer->createService(string)
13:03:48 #28 /workspace/src/includes/MediaWikiServices.php(295): Wikimedia\Services\ServiceContainer->getService(string)
13:03:48 #29 /workspace/src/vendor/wikimedia/services/src/ServiceContainer.php(424): MediaWiki\MediaWikiServices->getService(string)
13:03:48 #30 /workspace/src/vendor/wikimedia/object-factory/src/ObjectFactory.php(211): Wikimedia\Services\ServiceContainer->get(string)
13:03:48 #31 /workspace/src/vendor/wikimedia/object-factory/src/ObjectFactory.php(152): Wikimedia\ObjectFactory\ObjectFactory::getObjectFromSpec(array, array)
13:03:48 #32 /workspace/src/includes/HookContainer/HookContainer.php(473): Wikimedia\ObjectFactory\ObjectFactory->createObject(array)
13:03:48 #33 /workspace/src/includes/HookContainer/HookContainer.php(156): MediaWiki\HookContainer\HookContainer->getHandlers(string, array)
13:03:48 #34 /workspace/src/includes/HookContainer/HookRunner.php(2870): MediaWiki\HookContainer\HookContainer->run(string, array)
13:03:48 #35 /workspace/src/includes/parser/Parser.php(660): MediaWiki\HookContainer\HookRunner->onParserClearState(Parser)
13:03:48 #36 /workspace/src/includes/parser/Parser.php(4891): Parser->clearState()
13:03:48 #37 /workspace/src/includes/parser/Parser.php(4872): Parser->startParse(Title, ParserOptions, integer, boolean)
13:03:48 #38 /workspace/src/extensions/Scribunto/tests/phpunit/engines/LuaCommon/LuaEngineTestHelper.php(55): Parser->startExternalParse(Title, ParserOptions, integer, boolean)
13:03:48 #39 /workspace/src/extensions/Scribunto/tests/phpunit/engines/LuaCommon/LuaEngineTestBase.php(72): Scribunto_LuaEngineTestBase::makeSuite(string)
13:03:48 #40 [internal function]: Scribunto_LuaEngineTestBase::suite(string)
13:03:48 #41 /workspace/src/vendor/phpunit/phpunit/src/Framework/TestSuite.php(462): ReflectionMethod->invoke(NULL, string)
13:03:48 #42 /workspace/src/vendor/phpunit/phpunit/src/Framework/TestSuite.php(481): PHPUnit\Framework\TestSuite->addTestFile(string)
13:03:48 #43 /workspace/src/tests/phpunit/suites/ExtensionsTestSuite.php(31): PHPUnit\Framework\TestSuite->addTestFiles(array)
13:03:48 #44 /workspace/src/tests/phpunit/suites/ExtensionsTestSuite.php(43): ExtensionsTestSuite->__construct()
13:03:48 #45 [internal function]: ExtensionsTestSuite::suite(string)
13:03:48 #46 /workspace/src/vendor/phpunit/phpunit/src/Framework/TestSuite.php(462): ReflectionMethod->invoke(NULL, string)
13:03:48 #47 /workspace/src/vendor/phpunit/phpunit/src/Util/Configuration.php(1061): PHPUnit\Framework\TestSuite->addTestFile(string)
13:03:48 #48 /workspace/src/vendor/phpunit/phpunit/src/Util/Configuration.php(907): PHPUnit\Util\Configuration->getTestSuite(DOMElement, array)
13:03:48 #49 /workspace/src/vendor/phpunit/phpunit/src/TextUI/Command.php(963): PHPUnit\Util\Configuration->getTestSuiteConfiguration(string)
13:03:48 #50 /workspace/src/vendor/phpunit/phpunit/src/TextUI/Command.php(202): PHPUnit\TextUI\Command->handleArguments(array)
13:03:48 #51 /workspace/src/tests/phpunit/phpunit.php(36): PHPUnit\TextUI\Command->run(array, boolean)
13:03:48 #52 /workspace/src/tests/phpunit/phpunit.php(75): PHPUnitMaintClass->execute()
13:03:48 #53 {main}
13:03:48 INFO:quibble.commands:<<< Finish: User commands: extensions/Wikibase/build/jenkins/mw-apply-wb-settings.sh -r client, cp --verbose $WORKSPACE/src/LocalSettings.php $LOG_DIR, php maintenance/update.php --quick, php tests/phpunit/phpunit.php --verbose --log-junit "$LOG_DIR/junit-wikibase-client.xml" --group Wikibase,WikibaseClient, in 2.511 s

Change 804283 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] Change API tests from unit tests to integration tests

https://gerrit.wikimedia.org/r/804283

Ugh, this doesn’t work yet because there’s one more warning (and those also make gate-and-submit fail):

PHPUnit\Framework\WarningTestCase
 ⚠ Warning
   │
   │ The data provider specified for ApiStructureTest::testParameters is invalid.
   │ Wikimedia\Rdbms\DBConnectionError: Cannot access the database: Access denied for user 'wikiuser'@'localhost' to database 'centralauth' (localhost:/workspace/db/quibble-mysql-wc4x6073/socket)
   │ /workspace/src/includes/libs/rdbms/loadbalancer/LoadBalancer.php:1465
   │ /workspace/src/includes/libs/rdbms/loadbalancer/LoadBalancer.php:958
   │ /workspace/src/includes/libs/rdbms/loadbalancer/LoadBalancer.php:931
   │ /workspace/src/includes/libs/rdbms/database/DBConnRef.php:65
   │ /workspace/src/includes/libs/rdbms/database/DBConnRef.php:270
   │ /workspace/src/extensions/CentralAuth/includes/GlobalGroup/GlobalGroupLookup.php:56
   │ /workspace/src/extensions/CentralAuth/includes/Api/ApiQueryGlobalAllUsers.php:273
   │ /workspace/src/includes/api/ApiBase.php:1782
   │ /workspace/src/tests/phpunit/structure/ApiStructureTest.php:175
   │ phpvfscomposer:///workspace/src/vendor/phpunit/phpunit/phpunit:97

This is a unit test in core… should it also be an integration test? It tests that the parameter definitions of API modules are valid, and in CentralAuth that requires accessing the database so that the defined groups can be used for the group and excludegroup params. (Presumably, other APIs do something similar for tags parameters, that just doesn’t produce an error because the change_tag_def table would exist in the real wiki.)

If anyone is able to reproduce this error locally, please let me know. So far I haven't been able to, with the same set of extensions as CI.

Change 804305 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/core@master] phpunit: Temporary revert entrypoint to phpunit.php

https://gerrit.wikimedia.org/r/804305

Change 804319 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/core@master] DevelopmentSettings: Set CentralAuthDatabase to main DB name

https://gerrit.wikimedia.org/r/804319

Change 803918 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/core@master] Revert "phpunit: Default to vendor/bin/phpunit, remove suites.xml"

https://gerrit.wikimedia.org/r/803918

Change 803918 merged by jenkins-bot:

[mediawiki/core@master] Revert "phpunit: Default to vendor/bin/phpunit, remove suites.xml"

https://gerrit.wikimedia.org/r/803918

matmarex renamed this task from Wikibase\Client\Tests\Unit\Api\ApiFormatReferenceTest#testInvalidReferenceJson failure to PHPUnit failure in various extensions: Wikimedia\Rdbms\DBConnectionError: Cannot access the database: Access denied for user 'wikiuser'@'localhost' to database 'centralauth'.Jun 9 2022, 3:13 PM
matmarex subscribed.
Lucas_Werkmeister_WMDE lowered the priority of this task from Unbreak Now! to High.Jun 9 2022, 3:16 PM

No longer UBN!; I’ll leave @kostajh to decide whether this task should be kept open or closed, since the revert isn’t a permanent solution.

Change 804283 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Change API tests from unit tests to integration tests

https://gerrit.wikimedia.org/r/804283

Thank you all for your help. Now the tests pass again and changes can be merged. From a math perspective, the issue can be closed.

Change 804526 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/core@master] [DNM] phpunit: Default to vendor/bin/phpunit, remove suites.xml (take 2)

https://gerrit.wikimedia.org/r/804526

Change 804305 abandoned by Krinkle:

[mediawiki/core@master] phpunit: Temporarily revert entrypoint to phpunit.php

Reason:

https://gerrit.wikimedia.org/r/804305

Change 813209 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/core@master] phpunit: Add Integration/Unit bootstrap files

https://gerrit.wikimedia.org/r/813209

Change 813304 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[integration/config@master] jjb: [wkibase-kind-docker] Pass Wikibase directory to phpunit

https://gerrit.wikimedia.org/r/813304

Change 813304 abandoned by Kosta Harlan:

[integration/config@master] jjb: [wikibase-kind-docker] Pass Wikibase directory to phpunit

Reason:

Didn't work, let's find a solution elsewhere.

https://gerrit.wikimedia.org/r/813304

Change 804319 abandoned by Kosta Harlan:

[mediawiki/core@master] DevelopmentSettings: Set CentralAuthDatabase to main DB name

Reason:

https://gerrit.wikimedia.org/r/804319

kostajh claimed this task.

No longer UBN!; I’ll leave @kostajh to decide whether this task should be kept open or closed, since the revert isn’t a permanent solution.

This task is no longer relevant. Work to block access to main wiki DB in test scenarios can be tracked in the various vendor/bin/phpunit migration tasks (T90875 and subtasks).

Change 813209 abandoned by Kosta Harlan:

[mediawiki/core@master] phpunit: Add Integration/Unit bootstrap files

Reason:

https://gerrit.wikimedia.org/r/813209

Change 804526 abandoned by Kosta Harlan:

[mediawiki/core@master] phpunit: Default to vendor/bin/phpunit, remove suites.xml (take 2)

Reason:

https://gerrit.wikimedia.org/r/804526