Repository navigation
test: test-timers-unrefd-interval-still-fires.js flaky on smartOS #4559
Description
Activity
- addedtimersIssues and PRs related to timers, setImmediate(), setInterval(), and setTimeout().Issues and PRs related to timers, setImmediate(), setInterval(), and setTimeout().testIssues and PRs related to Node.js core tests and test infrastructure.Issues and PRs related to Node.js core tests and test infrastructure.smartosIssues and PRs related to the SmartOS platform.Issues and PRs related to the SmartOS platform.
on Jan 7, 2016 Current version fails stress test: https://ci.nodejs.org/job/node-stress-single-test/307/nodes=smartos14-64/console
This would appear to be a fulfillment of the prophecy of @misterdjules at #3550 (comment).
I've refactored the test to not rely on an arbitrary timeout as it is not a performance benchmark but a functionality test designed to check for a very specific bug.
The refactored test passes the stress test: https://ci.nodejs.org/job/node-stress-single-test/311/nodes=smartos14-64/console
PR: #4561
One of the aforementioned failures is particularly interesting:
# [FAIL] Interval fired 5/5 times. # /home/iojs/build/workspace/node-test-commit-smartos/nodes/smartos14-64/test/parallel/test-timers-unrefd-interval-still-fires.js:14 # throw new Error('Test timed out. keepOpen was not canceled.'); # ^ # # Error: Test timed out. keepOpen was not canceled. # at null._onTimeout (/home/iojs/build/workspace/node-test-commit-smartos/nodes/smartos14-64/test/parallel/test-timers-unrefd-interval-still-fires.js:14:9) # at Timer.listOnTimeout (timers.js:92:15)As far as I can tell, it isn't possible for this to happen. If it's 5/5 the timeout that throws that error will already be cancelled...
@Fishrock123 Perhaps a race condition caused by the
clearTimeout(keepOpen)being in asetImmediate()rather than just called directly? I'm not sure that's possible, but since the impossible is happening, something is up.Oh hmmm.
@Trott I can't find where I suggested that to be added, I forget why that was. It should be removed, I think. (The
setImmediate())@Fishrock123 My first attempt at a fix for this was to just remove the
setImmediate()(and convert arrow functions to ES5-compatible functions) and leave everything else: b954d83It was still flaky when stress tested, though:
https://ci.nodejs.org/job/node-stress-single-test/308/nodes=smartos14-64/consoleBut it did get rid of the
5/5. The failures were all4/5,3/5...The control stress test (against master) showed
5/5failures: https://ci.nodejs.org/job/node-stress-single-test/307/nodes=smartos14-64/consoleSo yeah, it looks like the
setImmediate()caused the5/5weirdness. (But fixing that did not fix the test flakiness.)At least that mystery is solved...
- added a commit that references this issue
on Jan 9, 2016 e071894 should workaround the issue for you, @thealphanerd. There's a more thorough fix that will hopefully land soon, but that should resolve this issue for you if you land it on LTS.
- added a commit that references this issue
on Jan 11, 2016 - added 2 commits that reference this issue
on Jan 11, 2016 - added a commit that references this issue
on Jan 28, 2016 - added 3 commits that reference this issue
on Feb 11, 2016 - added a commit that references this issue
on Apr 2, 2016 - added a commit that references this issue
on Jul 27, 2026
Seeing flaky results in LTS
https://ci.nodejs.org/job/node-test-commit-smartos/813/
https://ci.nodejs.org/job/node-test-commit-smartos/810/
Passes on job 811 and 812 though.
Running one more time to see if it fails again
https://ci.nodejs.org/job/node-test-commit-smartos/814/