-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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-regress-GH-4027 on Windows #13800
Comments
Yes this is a timing balancing act, supposed to do
|
Another one: 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)
... |
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 Increasing the delay before unlinking to 300ms and calling Created a PR: #14010 |
The sequential/test-regress-GH-4027 test is flaky with an increased system load, failing when the watched file is unlinked before the first state of the watched file is retrieved. After increasing the delay before unlinking and calling setTimeout after watchFile, the flakiness stopped reproducing. PR-URL: #14010 Fixes: #13800 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
The sequential/test-regress-GH-4027 test is flaky with an increased system load, failing when the watched file is unlinked before the first state of the watched file is retrieved. After increasing the delay before unlinking and calling setTimeout after watchFile, the flakiness stopped reproducing. PR-URL: #14010 Fixes: #13800 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
The sequential/test-regress-GH-4027 test is flaky with an increased system load, failing when the watched file is unlinked before the first state of the watched file is retrieved. After increasing the delay before unlinking and calling setTimeout after watchFile, the flakiness stopped reproducing. PR-URL: #14010 Fixes: #13800 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
The sequential/test-regress-GH-4027 test is flaky with an increased system load, failing when the watched file is unlinked before the first state of the watched file is retrieved. After increasing the delay before unlinking and calling setTimeout after watchFile, the flakiness stopped reproducing. PR-URL: #14010 Fixes: #13800 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
The sequential/test-regress-GH-4027 test is flaky with an increased system load, failing when the watched file is unlinked before the first state of the watched file is retrieved. After increasing the delay before unlinking and calling setTimeout after watchFile, the flakiness stopped reproducing. PR-URL: #14010 Fixes: #13800 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
The sequential/test-regress-GH-4027 test is flaky with an increased system load, failing when the watched file is unlinked before the first state of the watched file is retrieved. After increasing the delay before unlinking and calling setTimeout after watchFile, the flakiness stopped reproducing. PR-URL: #14010 Fixes: #13800 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
https://ci.nodejs.org/job/node-test-binary-windows/9310/RUN_SUBSET=1,VS_VERSION=vs2015,label=win2012r2/console
/cc @nodejs/testing @nodejs/platform-windows
Perhaps a race condition triggered by system load, which probably explains why it's in
sequential
and notparallel
in the first place?The text was updated successfully, but these errors were encountered: