Page MenuHomePhabricator

Jenkins jobs for MediaWiki fail due to ve.ui.MWWikitextStringTransferHandler having "pending AJAX requests"
Closed, ResolvedPublicPRODUCTION ERROR

Description

This particular QUnit test failure has been causing builds to fail in MediaWiki core and other extensions.

qunit
FAILED TESTS (1/1):

ve.ui.MWWikitextStringTransferHandler (Cite)
  ✖ convert

  Error: Pending AJAX requests: 1 (active: 1)

I'm unsure as to what code initiates the faulty/untracked Ajax request, but it's likely either the above test itself or a test shortly before it.

The debug log from the above Jenkins builds shows the last HTTP fetch to be for a url /null which seems like a bug, but might be unrelated.

00:11:12.519 03 09 2018 18:46:49.694:DEBUG [middleware:source-files]: Requesting /null /
00:11:12.520 03 09 2018 18:46:49.695:DEBUG [middleware:source-files]: Fetching /null
00:11:12.521 03 09 2018 18:46:49.696:DEBUG [proxy]: proxying request - /null to 127.0.0.1:9412

Event Timeline

Krinkle triaged this task as Unbreak Now! priority.Sep 3 2018, 7:05 PM
Krinkle renamed this task from QUnit test ve.ui.MWWikitextStringTransferHandler fails with "pending AJAX requests" to Jenkins jobs for MediaWiki fail due to ve.ui.MWWikitextStringTransferHandler having "pending AJAX requests".Sep 3 2018, 7:05 PM
Krinkle updated the task description. (Show Details)

I can reproduce this semi-consistently after setting a custom network throttling profile in Chromium debugger to delay all requests by 2000 ms.

After experimenting a bunch I'm pretty sure this is caused by the new test added in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/456629. Constructing a ve.init.mw.DesktopArticleTarget eventually calls setEditorPreference() (private function in ve.init.mw.DesktopArticleTarget.init.js), which makes some API requests to save user options, and we don't wait for them.

Change 457699 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@master] Revert "Follow-up I38eda4a: Add unit tests for lang/dir in target init"

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

@Krinkle Is there some convenient way to view failure rates and see if reverting that fixed the issue?

Change 457699 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Revert "Follow-up I38eda4a: Add unit tests for lang/dir in target init"

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

@matmarex The trend subpages of each Jenkins job might help, e.g. https://integration.wikimedia.org/ci/job/wmf-quibble-vendor-mysql-hhvm-docker/buildTimeTrend. Although keep in mind that it's normal for failures to show up given they (also) run against unmerged patch sets that may have genuine failures.

I don't think there is anything for me to verify here. Moving it to "Done" column on VisualEditor workboard.

matmarex claimed this task.

There is really no reason for this to stay open. I fixed it a week ago.

Ed worked out how to prevent this problem, and I just merged his commit that re-adds the test, hopefully without any more spurious failures: https://gerrit.wikimedia.org/r/457884

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