1) Special:RecentChanges shows lemmas in title links to lexemes:
false == true
running chrome
AssertionError: false == true
at Context.it (/workspace/src/extensions/WikibaseLexeme/tests/selenium/specs/special/recentchanges.js:38:3)
at Promise.F (/workspace/src/node_modules/core-js/library/modules/_export.js:36:28)Description
Description
Details
Details
Related Objects
Related Objects
- Mentioned In
- T220666: quibble-vendor-mysql-hhvm-docker fails in Wikibase
rEWLEf86e761e2a06: RecentChanges: run jobs before trying to assert
rEWLEc47389f8f0e2: RecentChanges: run jobs before trying to assert
rEWLEfc5fd2f82208: RecentChanges: run jobs before trying to assert
rEWLE33f70d3ed825: Temporarily skip a flaky selenium test
rEWLE3c86e6f96fad: Temporarily skip a flaky selenium test - Mentioned Here
- T220229: Merge Blocker: Test failures in WikibaseLexeme: Special:RecentChanges shows lemmas in title links to lexemes
T199446: Flaky Special:RecentChanges selenium test
T191600: Showing the lemma in recent changes
Event Timeline
Comment Actions
Right, this basically brings us back to the discussion that was happening in T199446 and in the related patch experiments done by some WMDE engineers.
To take the recent failure (T220229) as an example, here's what I believe happens:
- Edit is made with the API (namely, new lexeme is created)
- Once done, Special:RecentChanges is opened
- Driver is apparently too fast, as the just made edit has not made it to Recent Changes yet.
I see no real way to get around this, as, for valid reasons, Recent changes are populated asynchronously, hence it always be possible, that the recent changes page will be opened before the job updating recent changes has added data from recent edits.
Rather dumb approach I could think of would be to have test wait some arbitrary amount of time between making an edit, and opening the special page, but this does not seem like a sustainable approach. Things could get too slow and this is difficult to predict. Also, adding a "sleep" to all tests dealing with recent changes etc would likely make the duration of the test suite run even longer, while it does quite a significant amount of time already. I'd see this as a (rather annoying) hack that hopefully works for some time, but not really a solution.
We could also ignore testing integration of our tools with Recent Changes, but as Recent Changes is the critical part of wikis, and integral part of editor work flows, ignoring those parts of the system from automated testing seems wrong, to put mildly.
Any ideas how to deal with this?
Comment Actions
Change 502827 had a related patch set uploaded (by WMDE-leszek; owner: WMDE-leszek):
[mediawiki/extensions/WikibaseLexeme@master] Temporarily skip a flaky selenium test
Comment Actions
Change 502827 merged by jenkins-bot:
[mediawiki/extensions/WikibaseLexeme@master] Temporarily skip a flaky selenium test
Comment Actions
Change 502830 had a related patch set uploaded (by Pablo Grass (WMDE); owner: Pablo Grass (WMDE)):
[mediawiki/extensions/WikibaseLexeme@master] RecentChanges: run jobs before trying to assert
Comment Actions
Change 502830 merged by jenkins-bot:
[mediawiki/extensions/WikibaseLexeme@master] RecentChanges: run jobs before trying to assert
Comment Actions
With https://gerrit.wikimedia.org/r/502830 merged we expect the test to no longer be flaky.