Report from `split_group0`: There was 1 error: 1) CirrusSearch\Event\EventBusWeightedTagSerializerTest::testSetEvent with data set #2 (array(array(array(array(1))), false)) RuntimeException: Could not acquire lock for page ID '1'. /workspace/src/includes/deferred/LinksUpdate/LinksUpdate.php:166 (snip) /workspace/src/includes/deferred/DeferredUpdates.php:165 /workspace/src/includes/Storage/PageUpdater.php:980 /workspace/src/includes/page/WikiPage.php:1646 /workspace/src/tests/phpunit/MediaWikiIntegrationTestCase.php:371 /workspace/src/extensions/CirrusSearch/tests/phpunit/integration/Event/EventBusWeightedTagSerializerTest.php:125 Report from `split_group2`: There was 1 error: 1) Wikibase\Client\Tests\Unit\Usage\ParsoidUsageTrackingTest::testValidCovers RuntimeException: Could not acquire lock for page ID '1'. /workspace/src/includes/deferred/LinksUpdate/LinksUpdate.php:166 (snip) /workspace/src/includes/deferred/DeferredUpdates.php:165 /workspace/src/includes/Storage/PageUpdater.php:980 /workspace/src/includes/page/WikiPage.php:1646 /workspace/src/tests/phpunit/MediaWikiIntegrationTestCase.php:2639 /workspace/src/extensions/Wikibase/client/tests/phpunit/integration/includes/Usage/ParsoidUsageTrackingTest.php:117 /workspace/src/extensions/Wikibase/client/tests/phpunit/integration/includes/Usage/ParsoidUsageTrackingTest.php:113 /workspace/src/extensions/Wikibase/client/tests/phpunit/integration/includes/Usage/ParsoidUsageTrackingTest.php:44
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T225730 Reduce runtime of MW shared gate Jenkins jobs to 5 min | |||
| Open | None | T50217 Speed up MediaWiki PHPUnit build by running integration tests in parallel | |||
| Resolved | tstarling | T407954 PHPUnit parallel database tests can fail to acquire locks on the same page |
Event Timeline
Comment Actions
@kostajh @ArthurTaylor - is it something you're planning to work on, or do you want MediaWiki-Platform-Team to take care of this ticket?
Comment Actions
Still happen
https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php82/30382/console
1) ContentHandlerFunctionalTest::testPreSaveTransform RuntimeException: Could not acquire lock for page ID '3'. /workspace/src/includes/Deferred/LinksUpdate/LinksUpdate.php:169 /workspace/src/includes/Deferred/DeferredUpdates.php:444 /workspace/src/includes/Deferred/RefreshSecondaryDataUpdate.php:99 /workspace/src/includes/Deferred/DeferredUpdates.php:444 /workspace/src/includes/Deferred/DeferredUpdates.php:187 /workspace/src/includes/Deferred/DeferredUpdates.php:285 /workspace/src/includes/Deferred/DeferredUpdatesScope.php:226 /workspace/src/includes/Deferred/DeferredUpdatesScope.php:158 /workspace/src/includes/Deferred/DeferredUpdates.php:282 /workspace/src/includes/Deferred/DeferredUpdatesScope.php:229 /workspace/src/includes/Deferred/DeferredUpdatesScope.php:158 /workspace/src/includes/Deferred/DeferredUpdates.php:268 /workspace/src/includes/Deferred/DeferredUpdates.php:359 /workspace/src/includes/Deferred/DeferredUpdates.php:142 /workspace/src/includes/Deferred/DeferredUpdates.php:165 /workspace/src/includes/Storage/PageUpdater.php:952 /workspace/src/includes/Page/WikiPage.php:1663 /workspace/src/tests/phpunit/MediaWikiIntegrationTestCase.php:370 /workspace/src/tests/phpunit/structure/ContentHandlerFunctionalTest.php:83
Happen in productionas well T281714: RuntimeException: Could not acquire lock for page ID (via LinksUpdate)
Comment Actions
Not sure if there might be smaller solutions to this specific issue, but database concurrency is something we'll want to consider anyway when switching to paratest (and more broadly supporting local parallelization). For example, with SQLite we may need to have separate databases, as in https://github.com/AaronSchulz/mediawiki-developer-tools/blob/7b6b68803c84e5ffff332f4bb233125f4a85273c/config/ParatestSettings.php
Comment Actions
Do we need to switch to paratest, given that we have a working parallelization setup?
Comment Actions
Yeah, I think we should just use the standard tool for the job, not our in-house ad-hoc setup; unless there is something our setup does and paratest doesn't, of course, but I'm not aware of any such thing. I've always been under the impression that the ad-hoc setup was a temporary solution to benefit from parallelization while we couldn't use paratest, due to issues such as T345481; but those issues will need to be resolved anyway for PHPUnit 10, sooner or later, so... Our custom runner also has its shortcomings, such as T404107. Nothing major, but we won't have to worry about these once we switch to the industry standard.
(I'm also not completely sure about the "working" part; for example, I'm not sure if it'd work with SQLite, where DB concurrency is a bigger issue)
Comment Actions
T416637: quibble-apitests failing on unrelated patches is probably also a case of this (only with user ID 1 rather than page ID 1).
Comment Actions
Could SQLite WAL mode (allows concurrent readers alongside a writer) perhaps help here?
This comment was removed by Mhurd.
Comment Actions
In T427466, @tstarling says that https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1294488 fixes this, by simply not acquiring the locks. If I understand correctly, the key observation that allows this is that each test run has its own copy of the database tables, so database locks shared between the test runs make no sense and can be skipped.