Last modified: 2014-11-20 16:22:22 UTC
It seems that the "Unfinished animations" error is being attributed to the wrong module. From the code, it does not appear that mediawiki.api is using any jQuery animation timers (which would be surprising). However, https://integration.wikimedia.org/ci/job/mwext-GettingStarted-qunit/156/consoleFull shows: --- 23:16:55 mediawiki.api - getToken( pre-populated )...ERROR 23:16:55 >> Message: Teardown failed on getToken( pre-populated ): Unfinished animations: 1 --- The error is also not consistent. At https://gerrit.wikimedia.org/r/#/c/146291/ , the check on upload passed, while the one on merge failed.
This is happening on core changes too (https://integration.wikimedia.org/ci/job/mediawiki-core-qunit/26048/consoleFull), so it's probably not an extension bug. Bumping priority since reliability of continuous integration is important.
*** Bug 69448 has been marked as a duplicate of this bug. ***
It is still bitting core badly. Is there a way to reliably reproduce the issue? Would be nice to bisect and revert whatever cause the tests to be unstable.
(In reply to Antoine "hashar" Musso from comment #3) > It is still bitting core badly. Is there a way to reliably reproduce the > issue? Would be nice to bisect and revert whatever cause the tests to be > unstable. Someone can try running it locally, and/or in debug mode (sometimes stepping through helps). There is a runner at https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FFlow.git/3973d9b7161e3a9b6ebee7ccafc52f46af0eaaba/scripts%2Fqunit.sh that I used as a starting point when working on bug 63579 (which led to these messages, before such issues caused subtler failures).
It may not be reproducible in the browser, so the link shows how to use a PhantomJS runner.
Could be caused by an animation started via a timeout in some other test. The error is thrown by https://git.wikimedia.org/blob/mediawiki%2Fcore.git/5950ac2cef80cd69306458672adb4755fab60e98/tests%2Fqunit%2Fdata%2Ftestrunner.js#L249 $.timers is populated by jQuery.fx.timer, maybe that function could be decorated to store the call chain when timers are added? Just create an exception, log the stack trace, then discard it - the top of the stack should be some function passed to a setTimeout call, and that function can be used to identify the test which should use a fake timer but doesn't.
*** Bug 73189 has been marked as a duplicate of this bug. ***
(In reply to Tisza Gergő from comment #6) > Could be caused by an animation started via a timeout in some other test. > > The error is thrown by > https://git.wikimedia.org/blob/mediawiki%2Fcore.git/ > 5950ac2cef80cd69306458672adb4755fab60e98/tests%2Fqunit%2Fdata%2Ftestrunner. > js#L249 > > $.timers is populated by jQuery.fx.timer, maybe that function could be > decorated to store the call chain when timers are added? Just create an > exception, log the stack trace, then discard it - the top of the stack > should be some function passed to a setTimeout call, and that function can > be used to identify the test which should use a fake timer but doesn't. It'd be disproportionate effort to implement this as part of the test. But since the callstack is deterministic, it should be pretty straight forward to add some tracing locally when debugging this particular issue in e.g. Chrome to find out which animations are started. QUnit runs only one test at a time and always in the same order (some exceptions here, but not relevant in this case).
