21:27:43 1) phpunit\integration\PageChangeEmissionTest::testPageMove with data set "Valid move with redirect" ('SourcePageA', 'DestinationPageA', true, 3)
21:27:43 Failed asserting that two strings are equal.
21:27:43 --- Expected
21:27:43 +++ Actual
21:27:43 @@ @@
21:27:43 -'insert'
21:27:43 +'update'Description
Details
Related Objects
- Mentioned In
- T397103: Constant repeating notifications
- Mentioned Here
- rETMH11615886dbba: Sync up with Parsoid timedMediaHandlerParserTests.txt
T397103: Constant repeating notifications
rEEVBa7451509d1f7: PageChangeEmissionTest: integration test for move and undelete
T393890: EventBus: replace PageMoveCompleteHook with PageMovedEvent
Event Timeline
Seen here https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php83/4031/consoleFull, test introduced in rEEVBa7451509d1f7: PageChangeEmissionTest: integration test for move and undelete / T393890
I've seen this failure a couple of times now.
Change #1159767 had a related patch set uploaded (by Gmodena; author: Gmodena):
[mediawiki/extensions/EventBus@master] PageChangeEmissionTest: order move events by kind.
Maybe not.
I could not repro locally, but @dr0ptp4kt re-ran one the failing tests in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/1153121/comments/beb4ed88_de92a7fd
which completed successfully.
The most likely cause seems to be an issue with asserting events that arrived out of order (hook callbacks).
FYI: This is not Domain Events related; the affected test only touches Hooks (for now).
Saw this again in the GlobalBlocking extension: https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php81/10451/console#console-section-1
We also run into this in the FileImporter extension: https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php83/4414/console, via patch https://gerrit.wikimedia.org/r/1160745.
I can only make guesses at this point. Maybe it's another test that runs at the same time and creates a page with the same name? That could explain why we see an 'update' instead of the expected 'insert'. Can you check if this assertion is even critical for the test? Maybe it's fine to expect an 'insert' or 'update'?
My hunch is that this is a flaky test related to buggy timestamp ordering of events that were generated out-of-order (by hook callbacks). In this case the order of insertion and update matter,
so we can't relax this condition.
I have a patch that needs review / merge, that order events semantically instead of by time: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/EventBus/+/1159767
Change #1159767 merged by jenkins-bot:
[mediawiki/extensions/EventBus@master] PageChangeEmissionTest: order move events by kind.
Optimistically closing (hard to be sure whether it's resolved, given that the failure was nondeterministic). We can reopen if it happens again.
Change #1161588 had a related patch set uploaded (by Bartosz Dziewoński; author: Gmodena):
[mediawiki/extensions/EventBus@wmf/1.45.0-wmf.6] PageChangeEmissionTest: order move events by kind.
Change #1161588 merged by jenkins-bot:
[mediawiki/extensions/EventBus@wmf/1.45.0-wmf.6] PageChangeEmissionTest: order move events by kind.
Mentioned in SAL (#wikimedia-operations) [2025-06-19T20:26:26Z] <kharlan@deploy1003> Started scap sync-world: Backport for [[gerrit:1161588|PageChangeEmissionTest: order move events by kind. (T397087)]], [[gerrit:1161589|DomainEvents: Constant repeating notifications (T397103)]]
Mentioned in SAL (#wikimedia-operations) [2025-06-19T20:28:32Z] <kharlan@deploy1003> kharlan, matmarex: Backport for [[gerrit:1161588|PageChangeEmissionTest: order move events by kind. (T397087)]], [[gerrit:1161589|DomainEvents: Constant repeating notifications (T397103)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.
Mentioned in SAL (#wikimedia-operations) [2025-06-19T20:36:35Z] <kharlan@deploy1003> Finished scap sync-world: Backport for [[gerrit:1161588|PageChangeEmissionTest: order move events by kind. (T397087)]], [[gerrit:1161589|DomainEvents: Constant repeating notifications (T397103)]] (duration: 10m 08s)