GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — test: fix flaky timers-block-eventloop test by apapirovski · Pull Request #18567 · nodejs/node

Conversation

@apapirovski

@apapirovski apapirovski commented Feb 4, 2018 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor

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

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
@apapirovski
test: fix flaky timers-block-eventloop test
bbfb411 
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 Node.js core tests and test infrastructure. label Feb 4, 2018
apapirovski
apapirovski commented Feb 4, 2018
View reviewed changes
Comment thread test/sequential/test-timers-block-eventloop.js
setTimeout(function() {
fs.stat('/dev/nonexistent', () => {
assert(!called);
called = true;

@apapirovski apapirovski Feb 4, 2018

Copy link
Copy Markdown
Contributor Author

There was a problem hiding this comment.

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 :)

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
@apapirovski

apapirovski commented Feb 6, 2018

Copy link
Copy Markdown
Contributor 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.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
mcollina
mcollina approved these changes Feb 6, 2018
View reviewed changes

@mcollina mcollina left a comment

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

LGTM

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
@BridgeAR

BridgeAR commented Feb 6, 2018

Copy link
Copy Markdown
Member

Does this really still test the original issue?
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@apapirovski

apapirovski commented Feb 6, 2018 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor Author

@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
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@apapirovski

apapirovski commented Feb 7, 2018

Copy link
Copy Markdown
Contributor Author

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

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
BridgeAR
BridgeAR approved these changes Feb 8, 2018
View reviewed changes

@BridgeAR BridgeAR left a comment

Copy link
Copy Markdown
Member

There was a problem hiding this 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

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
@BridgeAR BridgeAR added the author ready PRs with CI started, the required approvals, and no outstanding review comments. label Feb 8, 2018
apapirovski added a commit that referenced this pull request Feb 8, 2018
@apapirovski
test: fix flaky timers-block-eventloop test
6963a93 
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 <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
@apapirovski

apapirovski commented Feb 8, 2018

Copy link
Copy Markdown
Contributor Author

Landed in 6963a93
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@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
@apapirovski @MylesBorins
test: fix flaky timers-block-eventloop test
59c1cfc 
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 <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
MylesBorins pushed a commit that referenced this pull request Feb 21, 2018
@apapirovski @MylesBorins
test: fix flaky timers-block-eventloop test
5d54a04 
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 <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
MylesBorins pushed a commit that referenced this pull request Feb 21, 2018
@apapirovski @MylesBorins
test: fix flaky timers-block-eventloop test
af3841b 
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 <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
@MylesBorins MylesBorins mentioned this pull request Feb 21, 2018
v9.6.0 proposal #18902
Merged
MylesBorins pushed a commit that referenced this pull request Feb 21, 2018
@apapirovski @MylesBorins
test: fix flaky timers-block-eventloop test
a667ac1 
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 <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
gibfahn pushed a commit that referenced this pull request Apr 13, 2018
@apapirovski @gibfahn
test: fix flaky timers-block-eventloop test
ab8edc9 
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 <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
gibfahn pushed a commit that referenced this pull request Apr 13, 2018
@apapirovski @gibfahn
test: fix flaky timers-block-eventloop test
44ab850 
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 <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
@gibfahn gibfahn added land-on-v6.x labels Apr 13, 2018
@MylesBorins MylesBorins mentioned this pull request Apr 13, 2018
v6.14.2 proposal #19996
Merged
@MylesBorins MylesBorins mentioned this pull request May 2, 2018
v8.11.2 proposal #20478
Merged
MayaLekova pushed a commit to MayaLekova/node that referenced this pull request May 8, 2018
@apapirovski @MayaLekova
test: fix flaky timers-block-eventloop test
4a1c10f 
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 <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@mcollina mcollina mcollina approved these changes
@BridgeAR BridgeAR BridgeAR approved these changes

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

author ready PRs with CI started, the required approvals, and no outstanding review comments. test Issues and PRs related to Node.js core tests and test infrastructure.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

5 participants

@apapirovski @BridgeAR @mcollina @gibfahn @nodejs-github-bot
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402520 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.