test-fs-watchfile failure on OSX - intermittent ?

Version: master
Platform: OSX
Subsystem: fs

Failure in CI testing PR with changes unrelated to fs watch

https://ci.nodejs.org/job/node-test-commit-osx/10086/nodes=osx1010/console

not ok 664 parallel/test-fs-watchfile
  ---
  duration_ms: 60.45
  severity: fail
  stack: |-
    timeout
  ...

stress run of 200 https://ci.nodejs.org/job/node-stress-single-test/1234/

I can replicate this locally with this command:

tools/test.py --repeat 100 -j 64 test/parallel/test-fs-watchfile.js

It doesn't trigger failures every time, but often enough that I haven't had to run it more than 5 times to get a failure yet.

This suggests that the issue is triggered by high load. Simple solution could be to move the test to sequential so it is not competing for resources with other tests.

One curiosity: When it times out with the above command line, it is always starting after the 36th or 37th successful run. Not sure what that means. But maybe someone more macOS savvy would. @nodejs/platform-macos

Maybe #13111

Probably my fault, I said it would work without common.refreshTmpDir()

Have a PR borrowing

@refack

@refack you had mentioned that having common.refreshTmpDir() in there could cause the test to fail on Windows. Is there anyway to avoid that?

Edit: After a quick test, it appears that this is still reproducible even after adding common.refreshTmpDir(). Still could be related to my changes though.

Yeah, make sure that you rmdir before.
Did it in #13251

I could be wrong, but I don't think removing files plays a part here.

I think the issue is that (on macOS at least) this is a race condition:

    fs.watch(dir, common.mustCall(function(eventType, filename) {
      this._handle.close();
      assert.strictEqual(filename, 'foo.txt');
    }));

    fs.writeFile(`${dir}/foo.txt`, 'foo', common.mustCall(function(err) {
      if (err) assert.fail(err);
    }));

My recollection is that (on macOS at least) you are not guaranteed to start receiving events write after fs.watch() returns.

Wrapping the fs.writeFile() in a setTimeout() for 100ms makes the test reliable on my machine. I'm going to test more, but if it holds up, I'll experiment a bit more with process.nextTick(), setImmediate(), etc. before opening a PR.

test: fix flaky test-fs-watchfile on macOS

Proposed fix in #13252

test: fix flaky test-fs-watchfile on macOS

test,fs: test fs.watch for `filename`

Navigation Menu

Repository navigation

test-fs-watchfile failure on OSX - intermittent ? #13248

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

test-fs-watchfile failure on OSX - intermittent ? #13248

Description

Activity

mhdawson commented on May 26, 2017

Trott commented on May 26, 2017

refack commented on May 26, 2017

refack commented on May 26, 2017

refack commented on May 27, 2017

chris--young commented on May 27, 2017

refack commented on May 27, 2017

Trott commented on May 27, 2017

Trott commented on May 27, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions