Occasional Wikibase CI failures: element (".lemma-widget_edit") still not visible after 10000ms
Closed, ResolvedPublic
Actions

Description

Example change: https://gerrit.wikimedia.org/r/534397
Example logs: https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php73-docker/3746/console

16:10:13 ==================================================================
16:10:13 Number of specs: 12
16:10:13 
16:10:13 
16:10:13 36 passing (162.90s)
16:10:13 4 skipped
16:10:13 1 failing
16:10:13 
16:10:13 1) Lexeme:Senses Gloss value unchanged after editing was cancelled:
16:10:13 element (".lemma-widget_edit") still not visible after 10000ms
16:10:13 running chrome
16:10:13 Error: element (".lemma-widget_edit") still not visible after 10000ms
16:10:13     at elements(".lemma-widget_edit") - isVisible.js:54:17
16:10:13     at isVisible(".lemma-widget_edit") - waitForVisible.js:73:22
16:10:13 
16:10:13 
16:10:13 npm ERR! code ELIFECYCLE
16:10:13 npm ERR! errno 1
16:10:13 npm ERR! @ selenium-test: `wdio tests/selenium/wdio.conf.js`
16:10:13 npm ERR! Exit status 1
16:10:13 npm ERR! 
16:10:13 npm ERR! Failed at the @ selenium-test script.
16:10:13 npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
16:10:13 
16:10:13 npm ERR! A complete log of this run can be found in:
16:10:13 npm ERR!     /cache/npm/_logs/2019-09-09T16_10_13_229Z-debug.log

Details

	Project	Branch	Lines +/-	Subject
	mediawiki/extensions/WikibaseLexeme	master	+10 -2	selenium: retry LexemePage.open() once

Customize query in gerrit

Related Objects

Mentioned In: T277205: Centrally look for flakey browser tests
T224546: Make WikibaseLexeme browser tests less flaky

Event Timeline

Lucas_Werkmeister_WMDE created this task.Sep 9 2019, 4:35 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 9 2019, 4:35 PM

Lucas_Werkmeister_WMDE added a project: Wikidata-Campsite.Sep 11 2019, 2:08 PM

Tagging the Structured Data on Commons folks since it affects their CI as well (example) :/

This seems to affect different tests, by the way – in the build for the change from the previous comment (console), the failing test is “Lexeme:Forms FormId counter is not decremented when addForm is undone”.

I assume the timeout is in LexemePage.open():

open( lexemeId ) {
    super.openTitle( 'Lexeme:' + lexemeId );
    browser.waitForVisible( this.constructor.LEMMA_WIDGET_SELECTORS.EDIT_BUTTON /* = '.lemma-widget_edit' */ );
    this.addFormLink.waitForVisible(); // last button on page, probably the last
}

And in “FormId counter is not decremented when addForm is undone”, that function is called like this:

const id = browser.call( () => LexemeApi.create().then( ( lexeme ) => lexeme.id ) );

LexemePage.open( id );

I wonder if there’s a race condition here, where we create the lexeme via the API but then the subsequent web request from LexemePage.open() is served from a replica that hasn’t seen the lexeme creation yet? (I think the LexemeApi and LexemePage use separate sessions – at least, LexemeApi logs in using a username/password from the environment while I don’t see any login in LexemePage – so this wouldn’t be prevented by ChronologyProtector.)

Change 537465 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseLexeme@master] selenium: retry LexemePage.open() once

https://gerrit.wikimedia.org/r/537465

gerritbot added a project: Patch-For-Review.Sep 17 2019, 3:17 PM

Lucas_Werkmeister_WMDE mentioned this in T224546: Make WikibaseLexeme browser tests less flaky.Sep 17 2019, 4:56 PM

Jdforrester-WMF added a subscriber: Jdforrester-WMF.Sep 17 2019, 5:04 PM

Change 537465 merged by jenkins-bot:
[mediawiki/extensions/WikibaseLexeme@master] selenium: retry LexemePage.open() once

https://gerrit.wikimedia.org/r/537465

ReleaseTaggerBot added a project: MW-1.35-notes (1.35.0-wmf.11; 2019-12-17).Dec 16 2019, 12:01 PM

Maintenance_bot removed a project: Patch-For-Review.Dec 16 2019, 12:10 PM