Page MenuHomePhabricator

MediaWiki PHPUnit test fails to "CREATE TEMPORARY TABLE `unittest_abuse_filter` (LIKE `abuse_filter`)"
Closed, ResolvedPublicPRODUCTION ERROR

Description

This database exception from AbuseFilter's tests is causing commits for MediaWiki core to fail sometimes (via the shared extension gate job).

https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/456023/
https://integration.wikimedia.org/ci/job/wmf-quibble-core-vendor-mysql-hhvm-docker/1540/consoleFull

INFO:test.run_phpunit:php tests/phpunit/phpunit.php --debug-tests --testsuite extensions --exclude-group Broken,ParserFuzz,Stub,Database
Using HHVM 3.18.6-dev (5.6.99-hhvm)
PHPUnit 4.8.36 by Sebastian Bergmann and contributors.


Fatal error: Uncaught exception 'Wikimedia\Rdbms\DBQueryError' with message 'A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? 
Query: CREATE TEMPORARY  TABLE `unittest_abuse_filter` (LIKE `abuse_filter`)
Function: Wikimedia\Rdbms\DatabaseMysqlBase::duplicateTableStructure
Error: 1005 Can't create table `wikidb`.`unittest_abuse_filter` (errno: 17 "File exists") (/tmp/quibble-mysql-fns46fdv/socket)
' in /workspace/src/includes/libs/rdbms/database/Database.php:1458
Stack trace:
#0 /workspace/src/includes/libs/rdbms/database/Database.php(1428): Wikimedia\Rdbms\Database->makeQueryException()
#1 /workspace/src/includes/libs/rdbms/database/Database.php(1198): Wikimedia\Rdbms\Database->reportQueryError()
#2 /workspace/src/includes/libs/rdbms/database/DatabaseMysqlBase.php(1446): Wikimedia\Rdbms\Database->query()
#3 /workspace/src/includes/db/CloneDatabase.php(112): Wikimedia\Rdbms\DatabaseMysqlBase->duplicateTableStructure()
#4 /workspace/src/tests/phpunit/MediaWikiTestCase.php(1394): CloneDatabase->cloneTableStructure()
#5 /workspace/src/tests/phpunit/MediaWikiTestCase.php(1461): MediaWikiTestCase::setupDatabaseWithTestPrefix()
#6 /workspace/src/tests/phpunit/MediaWikiTestCase.php(1414): MediaWikiTestCase::setupTestDB()
#7 /workspace/src/tests/phpunit/MediaWikiTestCase.php(470): MediaWikiTestCase->setupAllTestDBs()
#8 /workspace/src/vendor/phpunit/phpunit/src/Framework/TestSuite.php(722): MediaWikiTestCase->run()
#9 /workspace/src/vendor/phpunit/phpunit/src/Framework/TestSuite.php(722): PHPUnit_Framework_TestSuite->run()
#10 /workspace/src/vendor/phpunit/phpunit/src/Framework/TestSuite.php(722): PHPUnit_Framework_TestSuite->run()
#11 /workspace/src/vendor/phpunit/phpunit/src/TextUI/TestRunner.php(440): PHPUnit_Framework_TestSuite->run()
#12 /workspace/src/vendor/phpunit/phpunit/src/TextUI/Command.php(149): PHPUnit_TextUI_TestRunner->doRun()
#13 /workspace/src/vendor/phpunit/phpunit/src/TextUI/Command.php(100): PHPUnit_TextUI_Command->run()
#14 /workspace/src/tests/phpunit/phpunit.php(135): PHPUnit_TextUI_Command::main()
#15 /workspace/src/maintenance/doMaintenance.php(94): PHPUnitMaintClass->execute()
#16 /workspace/src/tests/phpunit/phpunit.php(174): include()
#17 {main}
[63c6318042b74cc57d404c16] [no req]   Wikimedia\Rdbms\DBQueryError from line 1458 of /workspace/src/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? 
Query: CREATE TEMPORARY  TABLE `unittest_abuse_filter` (LIKE `abuse_filter`)
Function: Wikimedia\Rdbms\DatabaseMysqlBase::duplicateTableStructure
Error: 1005 Can't create table `wikidb`.`unittest_abuse_filter` (errno: 17 "File exists") (/tmp/quibble-mysql-fns46fdv/socket)

Event Timeline

Huji triaged this task as Unbreak Now! priority.Aug 29 2018, 12:38 AM
Huji added a subscriber: Daimona.

Tagging Core-Platform-Team per mw:Maintainers and T185154.

Huji lowered the priority of this task from Unbreak Now! to High.Aug 29 2018, 1:25 AM
Huji subscribed.

Reducing priority, as that patch seems to have passed CI now.

I may be completely off track, but I think this happens when a unit test throws a fatal (and therefore, phpunit doesn't get a chance to remove the unittest_* tables) and a subsequent unit test is run for a different patch, which would fail upon phpunit trying to create that same unittest_* table.

In general, phpunit should NEVER end with a fatal. In reality, it can, see for instance T190898

CCicalese_WMF lowered the priority of this task from High to Medium.Aug 29 2018, 1:31 AM
CCicalese_WMF moved this task from Inbox to Backlog on the Core-Platform-Team-Old board.

If by "subsequent unit test" you are referring to a new invocation of PHPUnit by another Jenkins job build for another Gerrit event, that should not be possible because the tests run inside containers/VMs that are destroyed afterwards. They are not re-used. Each build of each Jenkins job, starts with a fresh container (for Docker jobs) or VM (for Nodepool jobs).

I think he meant the next test that is supposed to be run, so the tearDown() stuff isn't being called before it gets run?

I actually meant what Krinkle understood, and was obviously wrong. @Legoktm if PHPUnit ends with a fatal, not only the tearDown() won't be run but the next test wouldn't be run either, right?

The reason I am saying this is because I was once trying out one of @Daimona's patches that introduced new unit tests for AbuseFilter a few weeks ago, and it ended with a fatal somehow; later when I went into mysql I notted that the unittest_* tables where left there so I manually purged them.

Something seems very screwed up, these should only ever be temporary tables, they only exist for the single DB connection from which they were opened.

Note per the description this is happening with "--exclude-group Broken,ParserFuzz,Stub,Database"
So this shouldn't be running anything that interacts with the database anyway?

Well, I have no idea why this is happening, given that tests environments are destroyed (otherwise I'd have said the same as Huji). What Addshore said is also weird, since no DB should be involved. However, I'd like to focus your attention on another thing: in my local DB, and likely in CI's one too, abuse_filter is the first table in alphabetical order. Maybe that test instance had some troubles with DB not related to AbuseFilter and it reported a failure for the first table it tried to create.

I don't see how AbuseFilter could be related: no AF code is in the stacktrace above, since this happen during the setup of the test DB (i.e. before running any test). Also, the error code seems to refer to some kind of problem directly inside the workspace. I'm almost sure that, like I said in my last comment, this happens for the abuse_filter table just because it's the first one in alphabetical order.

Presumed fixed. Not seen for a while.

mmodell changed the subtype of this task from "Task" to "Production Error".Aug 28 2019, 11:09 PM