Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test: fix flaky timers-block-eventloop test #18567

Conversation

apapirovski
Copy link
Member

@apapirovski apapirovski commented Feb 4, 2018

Due to extensive reliance on timings and the fs module, this test
is currently inherently flaky. Refactor it to simply use setImmediate
and only one busy loop.

CI: https://ci.nodejs.org/job/node-test-pull-request/12934/

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

test

Due to extensive reliance on timings and the fs module, this test
is currently inherently flaky. Refactor it to simply use setImmediate
and only one busy loop.
@nodejs-github-bot nodejs-github-bot added the test Issues and PRs related to the tests. label Feb 4, 2018
setTimeout(function() {
fs.stat('/dev/nonexistent', () => {
assert(!called);
called = true;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is here to prevent an infinite loop before anyone asks :)

@apapirovski
Copy link
Member Author

ping @nodejs/collaborators — this is a test that has failed a few times recently. I would appreciate a review so we can continue making the CI a little less flaky.

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@BridgeAR
Copy link
Member

BridgeAR commented Feb 6, 2018

Does this really still test the original issue?

@apapirovski
Copy link
Member Author

apapirovski commented Feb 6, 2018

@BridgeAR yep, just in a very simplified way. It fails on all the same Node versions as the original test case. In fact, the previous test case wasn't even strictly correct which is why it was flaky. Here's an outline of what's going on:

  1. A "now" time gets recorded, let's call it 0
  2. First interval executes (close to no run time), gets added to the back of the interval list with startTime of 0 or 1
  3. Second interval executes, runs for 20ms
  4. We come back to the first interval since it is at the end of the list, the difference between 0 and 0 or 1 is smaller than 10, so it enters the if condition for deferral
  5. it checks the new now value which is now 20+ms ahead of the old now value, so the actual diff is now > 10ms, this means that it sets the timeRemaining to 0 or 1 (depending on whether the bug exists)
  6. If it sets it to 0, then when it comes back to C++, this list fires again and the test case fails

@apapirovski
Copy link
Member Author

@BridgeAR Did the explanation above make sense or do you still have concerns about this PR? I would like to land this.

Copy link
Member

@BridgeAR BridgeAR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the detailed description. LGTM

@BridgeAR BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Feb 8, 2018
apapirovski added a commit that referenced this pull request Feb 8, 2018
Due to extensive reliance on timings and the fs module, this test
is currently inherently flaky. Refactor it to simply use setImmediate
and only one busy loop.

PR-URL: #18567
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
@apapirovski
Copy link
Member Author

Landed in 6963a93

@apapirovski apapirovski closed this Feb 8, 2018
@apapirovski apapirovski deleted the fix-flaky-timers-block-eventloop branch February 8, 2018 20:34
MylesBorins pushed a commit that referenced this pull request Feb 21, 2018
Due to extensive reliance on timings and the fs module, this test
is currently inherently flaky. Refactor it to simply use setImmediate
and only one busy loop.

PR-URL: #18567
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
MylesBorins pushed a commit that referenced this pull request Feb 21, 2018
Due to extensive reliance on timings and the fs module, this test
is currently inherently flaky. Refactor it to simply use setImmediate
and only one busy loop.

PR-URL: #18567
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
MylesBorins pushed a commit that referenced this pull request Feb 21, 2018
Due to extensive reliance on timings and the fs module, this test
is currently inherently flaky. Refactor it to simply use setImmediate
and only one busy loop.

PR-URL: #18567
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
@MylesBorins MylesBorins mentioned this pull request Feb 21, 2018
MylesBorins pushed a commit that referenced this pull request Feb 21, 2018
Due to extensive reliance on timings and the fs module, this test
is currently inherently flaky. Refactor it to simply use setImmediate
and only one busy loop.

PR-URL: #18567
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
gibfahn pushed a commit that referenced this pull request Apr 13, 2018
Due to extensive reliance on timings and the fs module, this test
is currently inherently flaky. Refactor it to simply use setImmediate
and only one busy loop.

PR-URL: #18567
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
gibfahn pushed a commit that referenced this pull request Apr 13, 2018
Due to extensive reliance on timings and the fs module, this test
is currently inherently flaky. Refactor it to simply use setImmediate
and only one busy loop.

PR-URL: #18567
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
@MylesBorins MylesBorins mentioned this pull request Apr 13, 2018
@MylesBorins MylesBorins mentioned this pull request May 2, 2018
MayaLekova pushed a commit to MayaLekova/node that referenced this pull request May 8, 2018
Due to extensive reliance on timings and the fs module, this test
is currently inherently flaky. Refactor it to simply use setImmediate
and only one busy loop.

PR-URL: nodejs#18567
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants