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

Investigate flaky test-trace-events-fs-sync #43502

Closed
F3n67u opened this issue Jun 20, 2022 · 1 comment · Fixed by #43504
Closed

Investigate flaky test-trace-events-fs-sync #43502

F3n67u opened this issue Jun 20, 2022 · 1 comment · Fixed by #43504
Labels
flaky-test Issues and PRs related to the tests with unstable failures on the CI.

Comments

@F3n67u
Copy link
Member

F3n67u commented Jun 20, 2022

Test

test-trace-events-fs-sync

Platform

windows

Console output

C:\workspace\node-test-binary-windows-js-suites\node\test\parallel\test-trace-events-fs-sync.js:133
    throw new Error(`${tr}:\n${util.inspect(proc)}`);
    ^

Error: fs.sync.fstat:
{
  status: 1,
  signal: null,
  output: [
    null,
    '',
    'node:internal/fs/utils:347\r\n' +
      '    throw err;\r\n' +
      '    ^\r\n' +
      '\r\n' +
      "Error: EPERM: operation not permitted, open 'fs.txt'\r\n" +
      '    at Object.openSync (node:fs:599:3)\r\n' +
      '    at Object.writeFileSync (node:fs:2221:35)\r\n' +
      '    at [eval]:1:4\r\n' +
      '    at Script.runInThisContext (node:vm:130:12)\r\n' +
      '    at Object.runInThisContext (node:vm:306:38)\r\n' +
      '    at node:internal/process/execution:76:19\r\n' +
      '    at [eval]-wrapper:6:22\r\n' +
      '    at evalScript (node:internal/process/execution:75:60)\r\n' +
      '    at node:internal/main/eval_string:27:3 {\r\n' +
      '  errno: -4048,\r\n' +
      "  syscall: 'open',\r\n" +
      "  code: 'EPERM',\r\n" +
      "  path: 'fs.txt'\r\n" +
      '}\r\n' +
      '\r\n' +
      'Node.js v19.0.0-pre\r\n'
  ],
  pid: 2124,
  stdout: '',
  stderr: 'node:internal/fs/utils:347\r\n' +
    '    throw err;\r\n' +
    '    ^\r\n' +
    '\r\n' +
    "Error: EPERM: operation not permitted, open 'fs.txt'\r\n" +
    '    at Object.openSync (node:fs:599:3)\r\n' +
    '    at Object.writeFileSync (node:fs:2221:35)\r\n' +
    '    at [eval]:1:4\r\n' +
    '    at Script.runInThisContext (node:vm:130:12)\r\n' +
    '    at Object.runInThisContext (node:vm:306:38)\r\n' +
    '    at node:internal/process/execution:76:19\r\n' +
    '    at [eval]-wrapper:6:22\r\n' +
    '    at evalScript (node:internal/process/execution:75:60)\r\n' +
    '    at node:internal/main/eval_string:27:3 {\r\n' +
    '  errno: -4048,\r\n' +
    "  syscall: 'open',\r\n" +
    "  code: 'EPERM',\r\n" +
    "  path: 'fs.txt'\r\n" +
    '}\r\n' +
    '\r\n' +
    'Node.js v19.0.0-pre\r\n'
}
    at Object.<anonymous> (C:\workspace\node-test-binary-windows-js-suites\node\test\parallel\test-trace-events-fs-sync.js:133:11)
    at Module._compile (node:internal/modules/cjs/loader:1116:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1170:10)
    at Module.load (node:internal/modules/cjs/loader:994:32)
    at Module._load (node:internal/modules/cjs/loader:834:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47

Node.js v19.0.0-pre

Build links

https://ci.nodejs.org/job/node-test-binary-windows-js-suites/15223/

Additional information

This flaky test has been reported on those closed issues:

#25512, #22865, #22238, #21038

query this test nodejs/reliability: https://github.com/nodejs/reliability/issues?q=is%3Aissue+is%3Aopen+test-trace-events-fs-sync

@F3n67u F3n67u added the flaky-test Issues and PRs related to the tests with unstable failures on the CI. label Jun 20, 2022
@bnoordhuis
Copy link
Member

Making each sub-test operate on a unique file name will probably fix this. Right now they all open, modify and unlink a file called fs.txt. Unlink on Windows can put the file in limbo for a short while where it's almost-but-not-quite gone.

bnoordhuis added a commit to bnoordhuis/io.js that referenced this issue Jun 20, 2022
Should fix test flakiness that is presumably caused by the asynchronous
nature of the unlink operation on Windows.

It's been observed that sub-tests randomly fail with "permission denied"
errors when trying to create a new file in a directory with appropriate
permissions.

The DeleteFile() NT API call makes a file inaccessible and marks it for
deletion but doesn't actually delete it until the last open handle has
been closed. Accessing such a file fails with ERROR_ACCESS_DENIED.

Processes can close handles manually or wait for the operating system to
close them asynchronously after process termination. I speculate it's
the latter that's causing the test to turn flaky.

Fixes: nodejs#43502
nodejs-github-bot pushed a commit that referenced this issue Jun 22, 2022
Should fix test flakiness that is presumably caused by the asynchronous
nature of the unlink operation on Windows.

It's been observed that sub-tests randomly fail with "permission denied"
errors when trying to create a new file in a directory with appropriate
permissions.

The DeleteFile() NT API call makes a file inaccessible and marks it for
deletion but doesn't actually delete it until the last open handle has
been closed. Accessing such a file fails with ERROR_ACCESS_DENIED.

Processes can close handles manually or wait for the operating system to
close them asynchronously after process termination. I speculate it's
the latter that's causing the test to turn flaky.

Fixes: #43502

PR-URL: #43504
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: LiviaMedeiros <livia@cirno.name>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
F3n67u pushed a commit to F3n67u/node that referenced this issue Jun 24, 2022
Should fix test flakiness that is presumably caused by the asynchronous
nature of the unlink operation on Windows.

It's been observed that sub-tests randomly fail with "permission denied"
errors when trying to create a new file in a directory with appropriate
permissions.

The DeleteFile() NT API call makes a file inaccessible and marks it for
deletion but doesn't actually delete it until the last open handle has
been closed. Accessing such a file fails with ERROR_ACCESS_DENIED.

Processes can close handles manually or wait for the operating system to
close them asynchronously after process termination. I speculate it's
the latter that's causing the test to turn flaky.

Fixes: nodejs#43502

PR-URL: nodejs#43504
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: LiviaMedeiros <livia@cirno.name>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
targos pushed a commit that referenced this issue Jul 12, 2022
Should fix test flakiness that is presumably caused by the asynchronous
nature of the unlink operation on Windows.

It's been observed that sub-tests randomly fail with "permission denied"
errors when trying to create a new file in a directory with appropriate
permissions.

The DeleteFile() NT API call makes a file inaccessible and marks it for
deletion but doesn't actually delete it until the last open handle has
been closed. Accessing such a file fails with ERROR_ACCESS_DENIED.

Processes can close handles manually or wait for the operating system to
close them asynchronously after process termination. I speculate it's
the latter that's causing the test to turn flaky.

Fixes: #43502

PR-URL: #43504
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: LiviaMedeiros <livia@cirno.name>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
targos pushed a commit that referenced this issue Jul 20, 2022
Should fix test flakiness that is presumably caused by the asynchronous
nature of the unlink operation on Windows.

It's been observed that sub-tests randomly fail with "permission denied"
errors when trying to create a new file in a directory with appropriate
permissions.

The DeleteFile() NT API call makes a file inaccessible and marks it for
deletion but doesn't actually delete it until the last open handle has
been closed. Accessing such a file fails with ERROR_ACCESS_DENIED.

Processes can close handles manually or wait for the operating system to
close them asynchronously after process termination. I speculate it's
the latter that's causing the test to turn flaky.

Fixes: #43502

PR-URL: #43504
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: LiviaMedeiros <livia@cirno.name>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
targos pushed a commit that referenced this issue Jul 31, 2022
Should fix test flakiness that is presumably caused by the asynchronous
nature of the unlink operation on Windows.

It's been observed that sub-tests randomly fail with "permission denied"
errors when trying to create a new file in a directory with appropriate
permissions.

The DeleteFile() NT API call makes a file inaccessible and marks it for
deletion but doesn't actually delete it until the last open handle has
been closed. Accessing such a file fails with ERROR_ACCESS_DENIED.

Processes can close handles manually or wait for the operating system to
close them asynchronously after process termination. I speculate it's
the latter that's causing the test to turn flaky.

Fixes: #43502

PR-URL: #43504
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: LiviaMedeiros <livia@cirno.name>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
guangwong pushed a commit to noslate-project/node that referenced this issue Oct 10, 2022
Should fix test flakiness that is presumably caused by the asynchronous
nature of the unlink operation on Windows.

It's been observed that sub-tests randomly fail with "permission denied"
errors when trying to create a new file in a directory with appropriate
permissions.

The DeleteFile() NT API call makes a file inaccessible and marks it for
deletion but doesn't actually delete it until the last open handle has
been closed. Accessing such a file fails with ERROR_ACCESS_DENIED.

Processes can close handles manually or wait for the operating system to
close them asynchronously after process termination. I speculate it's
the latter that's causing the test to turn flaky.

Fixes: nodejs/node#43502

PR-URL: nodejs/node#43504
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: LiviaMedeiros <livia@cirno.name>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flaky-test Issues and PRs related to the tests with unstable failures on the CI.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants