Investigate flaky test-regress-GH-4027 on Windows #13800

Activity

1. Trott

   added

   fsIssues and PRs related to file-system APIs and the fs module.Issues and PRs related to file-system APIs and the fs module.

   testIssues and PRs related to Node.js core tests and test infrastructure.Issues and PRs related to Node.js core tests and test infrastructure.

   windowsIssues and PRs related to the Windows platform.Issues and PRs related to the Windows platform.

   on Jun 19, 2017
2. refack commented on Jun 19, 2017

   

   refack

   on Jun 19, 2017

   Contributor

   More actions

   Perhaps a race condition triggered by system load, which probably explains why it's in sequential and not parallel in the first place?

   Yes this is a timing balancing act, supposed to do

   1. fs.writeFileSync
   2. setTimeout(fs.unlinkSync, 100
   3. fs.watchFile(filename, { interval: 50 }
3. Trott commented on Jun 25, 2017

   

   Trott

   on Jun 25, 2017

   MemberAuthor

   More actions

   Another one:

   https://ci.nodejs.org/job/node-test-binary-windows/9429/RUN_SUBSET=3,VS_VERSION=vs2015,label=win2012r2/console

   not ok 387 sequential/test-regress-GH-4027
     ---
     duration_ms: 6.187
     severity: fail
     stack: |-
       assert.js:60
         throw new errors.AssertionError({
         ^
       
       AssertionError [ERR_ASSERTION]: 0 === 1
           at StatWatcher.<anonymous> (c:\workspace\node-test-binary-windows\RUN_SUBSET\3\VS_VERSION\vs2015\label\win2012r2\test\sequential\test-regress-GH-4027.js:35:10)
           at StatWatcher.<anonymous> (c:\workspace\node-test-binary-windows\RUN_SUBSET\3\VS_VERSION\vs2015\label\win2012r2\test\common\index.js:520:15)
           at emitTwo (events.js:125:13)
           at StatWatcher.emit (events.js:213:7)
           at StatWatcher._handle.onchange (fs.js:1454:10)
     ...
4. jaimecbernardo commented on Jun 30, 2017

   

   jaimecbernardo

   on Jun 30, 2017

   Contributor

   More actions

   Investigated this issue. Managed to replicate it on a VM by capping the CPU. The issue seems to be that the watched file is getting deleted before the internals of watchFile are able to get the first state of the file, so watchFile behaves as if the file doesn't exist and calls the callback with prev.nlink and curr.nlink at 0.

   Increasing the delay before unlinking to 300ms and calling setTimeout after watchFile caused it to stop reproducing.

   Created a PR: #14010
5. Trott

   closed this as completedin f1c890aon Jul 3, 2017
6. addaleax

   added a commit that references this issue on Jul 11, 2017

   test,fs: delay unlink in test-regress-GH-4027.js

   ...

   2daff32
7. addaleax

   added a commit that references this issue on Jul 18, 2017

   test,fs: delay unlink in test-regress-GH-4027.js

   ...

   b9e07f9
8. Fishrock123

   added a commit that references this issue on Jul 19, 2017

   test,fs: delay unlink in test-regress-GH-4027.js

   ...

   95ed925
9. MylesBorins

   added 3 commits that reference this issue on Aug 15, 2017

   test,fs: delay unlink in test-regress-GH-4027.js

   ...

   03a5c5a

   test,fs: delay unlink in test-regress-GH-4027.js

   ...

   f9a472f

   test,fs: delay unlink in test-regress-GH-4027.js

   ...

   f3c0b8c
10. sjarmak

    added a commit that references this issue on Jul 27, 2026

    test,fs: delay unlink in test-regress-GH-4027.js

    ...

    f1c890a