Investigate flaky test-fs-watch-non-recursive on Windows

[targos]

• Test: test-fs-watch-non-recursive
• Platform: Windows
• Console Output:

node:assert:171
  throw err;
  ^

AssertionError [ERR_ASSERTION]: function should not have been called at C:\workspace\node-test-binary-windows-js-suites\node\test\pummel\test-fs-watch-non-recursive.js:43
called with arguments: 'change', 'testsubdir'
    at FSWatcher.mustNotCall (C:\workspace\node-test-binary-windows-js-suites\node\test\common\index.js:479:12)
    at FSWatcher.emit (node:events:390:28)
    at FSEvent.FSWatcher._handle.onchange (node:internal/fs/watchers:212:12) {
  generatedMessage: false,
  code: 'ERR_ASSERTION',
  actual: undefined,
  expected: undefined,
  operator: 'fail'
}

• Build Links:
  https://ci.nodejs.org/job/node-test-binary-windows-js-suites/12089/RUN_SUBSET=2,nodes=win10-COMPILED_BY-vs2019/testReport/junit/(root)/test/pummel_test_fs_watch_non_recursive/

[joyeecheung]

It seems this first appears in nodejs/reliability#92, the referenced PRs don't seem to be related so I suspect it's an issue with the test.

[targos]

I'm am totally unable to make this test pass on my Windows machine, even if I increase the timeouts.
Maybe the issue is with some recent Windows update?

[Trott]

@nodejs/platform-windows

[Flarna]

It seems that the creation of file testsubdir/watch.txt changes the modification time of testsubdir - which seems correct to me.

I wonder that this test ever passed.

Adding e.g. fs.writeFileSync(filepath, 'init'); before starting the watcher avoids this and test passes on my machine. But I'm not sure if this changes the intention of test.

[joyeecheung]

It seems that the creation of file testsubdir/watch.txt changes the modification time of testsubdir - which seems correct to me.

The commit that added this test was 515607a with the message

fs: make fs.watch() non-recursive by default
Fixes a behavioral regression introduced in commit 691b9eb.

So I guess the intended behavior is that the changes shouldn't be notified in this case.

I looked into the logs a bit more and it seems this first (as far as the reliability bot records) appeared in nodejs/reliability#68, none of the referenced PRs seem to be related, either. I'd say it's time to mark this as flaky already.

[lpinca]

I've opened #40916 but I'm unable to reproduce the issue on my Windows machine.

$ npx envinfo --system

  System:
    OS: Windows 10 10.0.19044
    CPU: (8) x64 Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
    Memory: 3.88 GB / 7.90 GB

[targos]

Windows 10 10.0.19044

Is this the latest version of Windows 10?

[lpinca]

Yes, updated a few minutes ago.

[Flarna]

I tested again on a different (slower) Windows machine. Problem is not reproducible there but once I have VSCode running in background the test starts to fail (still executed without debugger from command line).

Maybe VSCode does also some watching which causes such side effects.

On the machine I tested first the test is flaky without VSCode running but fails stable if it runs in background.

[lpinca]

I've VSCode and a virtual machine (Windows 10 on Hyper-V) running but I can't reproduce.