This doesn't cause any build failures, but it looks rather confusing.
At the end of most PHPUnit jobs, the following is printed:
Time: 5.94 minutes, Memory: 1153.67MB OK, but incomplete, skipped, or risky tests! Tests: 20182, Assertions: 154688, Skipped: 112. Warning: Destructor threw an object exception: exception 'Wikimedia\Rdbms\DBAccessError' with message 'Database access has been disabled.' in /workspace/src/includes/libs/rdbms/loadbalancer/LoadBalancer.php:1108 Stack trace: #0 /workspace/src/includes/libs/rdbms/loadbalancer/LoadBalancer.php(933): Wikimedia\Rdbms\LoadBalancer->reallyOpenConnection() #1 /workspace/src/includes/libs/rdbms/loadbalancer/LoadBalancer.php(881): Wikimedia\Rdbms\LoadBalancer->openLocalConnection() #2 /workspace/src/includes/libs/rdbms/loadbalancer/LoadBalancer.php(757): Wikimedia\Rdbms\LoadBalancer->openConnection() #3 /workspace/src/includes/GlobalFunctions.php(2655): Wikimedia\Rdbms\LoadBalancer->getConnection() #4 /workspace/src/extensions/CentralAuth/includes/CentralAuthHooks.php(1518): wfGetDB() #5 /workspace/src/includes/Hooks.php(174): CentralAuthHooks::onUnitTestsBeforeDatabaseTeardown() #6 /workspace/src/includes/Hooks.php(202): Hooks::callHook() #7 /workspace/src/tests/phpunit/MediaWikiTestCase.php(1359): Hooks::run() #8 /workspace/src/tests/phpunit/bootstrap.php(20): MediaWikiTestCase::teardownTestDB() #9 (): MediaWikiPHPUnitBootstrap->__destruct()
The wrapper that MediaWiki uses around PHPUnit uses the __destruct interface to run code after PHPUnit is done (but before the program actually exits with the exit status code that PHPUnit decided on).
This is done that way because PHPUnit will call exit(), hence we cannot normally run code "after" the last test. There is also no built-in method for that purpose within the PHPUnit interface (actually, PHPUnit 8 does, but we're still on PHPUnit 4 + 6).
The problem with __destruct is that it doesn't run at a deterministic time. In the case of the above example, it ran after the database objects were already garbage collected, which means trying to access it will actually create a fresh state, and leads to a post-shutdown fatal error, which weirdly, isn't actually fatal.
This task is to find a different way to run MediaWikiTestCase::teardownTestDB. It should:
- Run exactly once, after the last test (regardless of whether tests passed or failed).
- Actually work. – E.g. run before the PHP engine state starts getting garbage collected, as currently it sometimes runs after that, and thus produce a fatal error as shown above.