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 fs-watch-recursive flakiness #4629

Merged
merged 1 commit into from
Sep 1, 2016

Conversation

santigimeno
Copy link
Member

The test is sometimes timing out because of a race condition between
the fs event generated on file creation and the event being registered
in the kqueue. To avoid this problem, create the file after 100 ms,
that is the value used in the libuv test:
https://github.com/libuv/libuv/blob/v1.x/test/test-fs-event.c#L411

@Trott
Copy link
Member

Trott commented Jan 11, 2016

I really want their to be a better solution than "introduce a 100ms delay" but I don't know that there is a better solution. I suppose it theoretically may be possible to introduce a ready event that fires for fs.FSWatcher but then again, it might not be possible or only on some operating systems.

Speaking of which, what OS are you seeing this problem on? OS X?

@silverwind silverwind added test Issues and PRs related to the tests. fs Issues and PRs related to the fs subsystem / file system. labels Jan 11, 2016
@santigimeno
Copy link
Member Author

Yes, I thought about the ready event too.
I'm seeing it on OS X.

@jasnell
Copy link
Member

jasnell commented Jan 12, 2016

Yeah, unfortunately right now I don't think there is a better solution :-(

@Trott
Copy link
Member

Trott commented Jan 21, 2016

Can we try this with setImmediate() instead of the setTimeout() and see if that fixes the issue? I'd prefer that if it will work.

Ref: #4776

@santigimeno
Copy link
Member Author

@Trott Unfortunately still times out :(

@jasnell
Copy link
Member

jasnell commented Mar 22, 2016

@santigimeno @Trott ... any updates on this one?

@Trott
Copy link
Member

Trott commented Mar 22, 2016

I'm OK with the timer if it's the only way we can come up with right now to make it less flaky. Maybe there's a feature request hiding in this problem for an event to be fired when the watcher is really watching.

@Trott
Copy link
Member

Trott commented Mar 22, 2016

LGTM if @santigimeno is happy with it.

@Trott
Copy link
Member

Trott commented Mar 22, 2016

(Note that it still needs a CI run, I think.)

@jasnell
Copy link
Member

jasnell commented Mar 22, 2016

@santigimeno
Copy link
Member Author

I'm OK until we find a better way.

@estliberitas estliberitas force-pushed the master branch 2 times, most recently from 7da4fd4 to c7066fb Compare April 26, 2016 05:22
@jasnell
Copy link
Member

jasnell commented Apr 30, 2016

Ping... @santigimeno @Trott ... any updates on this?

@Trott
Copy link
Member

Trott commented Apr 30, 2016

It's been off my radar. Maybe @santigimeno knows (for example) if the test is still flaky and needs this fix.

@santigimeno
Copy link
Member Author

@Trott @jasnell I'm still seeing these failures in my OS X box. I'm also seeing similar failures in other fs-watch tests: test-fs-watch.js and test-fs-watch-encoding.js. I can land it if you're still OK with it, or we can wait until the flakiness happens in our CI. WDYT?

@jasnell
Copy link
Member

jasnell commented Apr 30, 2016

I've seen flakiness here from time to time building locally but it's
extremely rare. Curious, which OS x version are you on? I'd say let's hold
off still until it becomes an issue on CI
On Apr 30, 2016 6:24 AM, "Santiago Gimeno" notifications@github.com wrote:

@Trott https://github.com/Trott @jasnell https://github.com/jasnell
I'm still seeing these failures in my OS X box. I'm also seeing similar
failures in other fs-watch tests: test-fs-watch.js and
test-fs-watch-encoding.js. I can land it if you're still OK with it, or
we can wait until the flakiness happens in our CI. WDYT?


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#4629 (comment)

@santigimeno
Copy link
Member Author

which OS x version are you on?

10.11.4

I'd say let's hold off still until it becomes an issue on CI

OK!

@santigimeno
Copy link
Member Author

@Trott
Copy link
Member

Trott commented Jun 16, 2016

OK, I think we should get this landed, but one other suggestion: Should we wrap the setTimeout() in a check for the OS so we only do that on OS X?

@santigimeno santigimeno force-pushed the test-fs-watch-recursive branch from 465fcd2 to e2905d2 Compare July 1, 2016 21:04
@santigimeno
Copy link
Member Author

@Trott updated!

@Trott
Copy link
Member

Trott commented Jul 1, 2016

LGTM. @nodejs/testing

@Trott
Copy link
Member

Trott commented Jul 1, 2016

Nit: Maybe put in a brief comment explaining the need for the setTimeout on OS X. (kqueue or whatever can send events out of order, or whatever the correct explanation is. Maybe doesn't even need to get that detailed. Just link to this issue or something.)

@Trott
Copy link
Member

Trott commented Jul 2, 2016

@rvagg
Copy link
Member

rvagg commented Aug 31, 2016

ping, can we get movement on this?

timeout failure on osx @ https://ci.nodejs.org/job/node-test-commit-linux/4919/nodes=ubuntu1204-clang341-64

@rvagg rvagg mentioned this pull request Aug 31, 2016
2 tasks
@Trott
Copy link
Member

Trott commented Sep 1, 2016

CI (since previous CI's are expired and 404'ing): https://ci.nodejs.org/job/node-test-pull-request/3916/

@Trott
Copy link
Member

Trott commented Sep 1, 2016

AIX build failure is unrelated. Waiting on ubuntu1604_docker_alpine34-64 but everything looks good. Still LGTM.

The test is sometimes timing out because of a race condition between
the fs event generated on file creation and the event being registered
in the kqueue. To avoid this problem, create the file after 100 ms,
that is the value used in the `fs_event_watch_dir_recursive` libuv test.

PR-URL: nodejs#4629
Reviewed-By: Rich Trott <rtrott@gmail.com>
@santigimeno santigimeno force-pushed the test-fs-watch-recursive branch from e2905d2 to a133b77 Compare September 1, 2016 17:29
@santigimeno santigimeno merged commit a133b77 into nodejs:master Sep 1, 2016
@santigimeno
Copy link
Member Author

Landed in a133b77

@Fishrock123 Fishrock123 mentioned this pull request Sep 6, 2016
Fishrock123 pushed a commit to Fishrock123/node that referenced this pull request Sep 8, 2016
The test is sometimes timing out because of a race condition between
the fs event generated on file creation and the event being registered
in the kqueue. To avoid this problem, create the file after 100 ms,
that is the value used in the `fs_event_watch_dir_recursive` libuv test.

PR-URL: nodejs#4629
Reviewed-By: Rich Trott <rtrott@gmail.com>
Fishrock123 pushed a commit that referenced this pull request Sep 9, 2016
The test is sometimes timing out because of a race condition between
the fs event generated on file creation and the event being registered
in the kqueue. To avoid this problem, create the file after 100 ms,
that is the value used in the `fs_event_watch_dir_recursive` libuv test.

PR-URL: #4629
Reviewed-By: Rich Trott <rtrott@gmail.com>
MylesBorins pushed a commit that referenced this pull request Oct 10, 2016
The test is sometimes timing out because of a race condition between
the fs event generated on file creation and the event being registered
in the kqueue. To avoid this problem, create the file after 100 ms,
that is the value used in the `fs_event_watch_dir_recursive` libuv test.

PR-URL: #4629
Reviewed-By: Rich Trott <rtrott@gmail.com>
MylesBorins pushed a commit that referenced this pull request Oct 10, 2016
The test is sometimes timing out because of a race condition between
the fs event generated on file creation and the event being registered
in the kqueue. To avoid this problem, create the file after 100 ms,
that is the value used in the `fs_event_watch_dir_recursive` libuv test.

PR-URL: #4629
Reviewed-By: Rich Trott <rtrott@gmail.com>
rvagg pushed a commit that referenced this pull request Oct 18, 2016
The test is sometimes timing out because of a race condition between
the fs event generated on file creation and the event being registered
in the kqueue. To avoid this problem, create the file after 100 ms,
that is the value used in the `fs_event_watch_dir_recursive` libuv test.

PR-URL: #4629
Reviewed-By: Rich Trott <rtrott@gmail.com>
MylesBorins pushed a commit that referenced this pull request Oct 26, 2016
The test is sometimes timing out because of a race condition between
the fs event generated on file creation and the event being registered
in the kqueue. To avoid this problem, create the file after 100 ms,
that is the value used in the `fs_event_watch_dir_recursive` libuv test.

PR-URL: #4629
Reviewed-By: Rich Trott <rtrott@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Oct 26, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fs Issues and PRs related to the fs subsystem / file system. test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants