You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Investigate flaky test-fs-watch-non-recursive on Windows #40728
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'
}
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?
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.
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.
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.
Activity
joyeecheung commentedon Nov 8, 2021
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 commentedon Nov 8, 2021
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 commentedon Nov 9, 2021
@nodejs/platform-windows
Flarna commentedon Nov 14, 2021
It seems that the creation of file
testsubdir/watch.txtchanges the modification time oftestsubdir- 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 commentedon Nov 15, 2021
The commit that added this test was 515607a with the message
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.
test: mark test-fs-watch-non-recursive flaky on Windows
lpinca commentedon Nov 22, 2021
I've opened #40916 but I'm unable to reproduce the issue on my Windows machine.
targos commentedon Nov 22, 2021
Is this the latest version of Windows 10?
lpinca commentedon Nov 22, 2021
Yes, updated a few minutes ago.
Flarna commentedon Nov 22, 2021
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 commentedon Nov 22, 2021
I've VSCode and a virtual machine (Windows 10 on Hyper-V) running but I can't reproduce.
test: mark test-fs-watch-non-recursive flaky on Windows
test: mark test-fs-watch-non-recursive flaky on Windows
test: mark test-fs-watch-non-recursive flaky on Windows
test: mark test-fs-watch-non-recursive flaky on Windows
Revert "test: mark test-fs-watch-non-recursive flaky on Windows"
Revert "test: mark test-fs-watch-non-recursive flaky on Windows"
Revert "test: mark test-fs-watch-non-recursive flaky on Windows"
Revert "test: mark test-fs-watch-non-recursive flaky on Windows"