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
I'm able to reproduce this locally with tools/test.py --repeat 1024 test/parallel/test-inspector-multisession-ws.js It seems to fail once every few hundred runs.
I was able to reproduce test/parallel/test-inspector-wait-for-connection.js locally somewhat consistently by doing tools/test.py --repeat 512 -j8 test/parallel/test-inspector-wait-for-connection.js. The higher the parallelism, the more frequently it seems to happen.
After some digging it looks like (at least for test/parallel/test-inspector-wait-for-connection.js) console.log('before wait for debugger') is called on the child process, then everything is executed on the parent process, causing Runtime.runIfWaitingForDebugger to be sent before the child process can call inspector.waitForDebugger(). Since there's no way for the child process to communicate to the parent process that it's waiting, this becomes non-determininstic and sometimes it fails.
I think the best way to fix these tests would be to add a NodeRuntime.waitingForDebugger and maybe also a NodeWorker.waitingForDebugger, both would be sent when the domain is enabled (if the runtime is waiting for debugger), or when inspector.waitForDebugger() is called. Seems like something that would be useful both for our internal tests as well as libraries/tools so that they don't need to rely on guessing if the runtime is waiting for the debugger or not. I'm happy to send a PR if that seems like a reasonable approach.
Activity
mhdawson commentedon Oct 9, 2020
Occurred in CI run today as well: https://ci.nodejs.org/job/node-test-commit-osx/36606/
Trott commentedon Apr 2, 2021
https://ci.nodejs.org/job/node-test-commit-osx/39832/nodes=osx1015/console
Trott commentedon Apr 2, 2021
I'm able to reproduce this locally with
tools/test.py --repeat 1024 test/parallel/test-inspector-multisession-ws.jsIt seems to fail once every few hundred runs.Trott commentedon Apr 14, 2021
https://ci.nodejs.org/job/node-test-commit-osx/40090/nodes=osx1015/console
Trott commentedon Apr 15, 2021
It's pausing and stalling here:
node/test/common/inspector-helper.js
Lines 246 to 247 in c3a5e15
tniessen commentedon Mar 30, 2023
Another failure: https://ci.nodejs.org/job/node-test-commit-osx/51271/nodes=osx1015/
mmarchini commentedon Jun 26, 2023
Same error seems to be happening on other tests:
I was able to reproduce
test/parallel/test-inspector-wait-for-connection.jslocally somewhat consistently by doingtools/test.py --repeat 512 -j8 test/parallel/test-inspector-wait-for-connection.js. The higher the parallelism, the more frequently it seems to happen.After some digging it looks like (at least for
test/parallel/test-inspector-wait-for-connection.js) console.log('before wait for debugger') is called on the child process, then everything is executed on the parent process, causing Runtime.runIfWaitingForDebugger to be sent before the child process can call inspector.waitForDebugger(). Since there's no way for the child process to communicate to the parent process that it's waiting, this becomes non-determininstic and sometimes it fails.I think the best way to fix these tests would be to add a
NodeRuntime.waitingForDebuggerand maybe also aNodeWorker.waitingForDebugger, both would be sent when the domain is enabled (if the runtime is waiting for debugger), or wheninspector.waitForDebugger()is called. Seems like something that would be useful both for our internal tests as well as libraries/tools so that they don't need to rely on guessing if the runtime is waiting for the debugger or not. I'm happy to send a PR if that seems like a reasonable approach.mmarchini commentedon Jun 29, 2023
ok I think I have a fix for the flakiness, it's affecting quite a few inspector tests so I'm updating all of them before sending a PR
joyeecheung commentedon Nov 16, 2023
The inspector test flakes are still low-key lurking in the CI. @mmarchini are you still working on it?
inspector: add NodeRuntime.waitingForDebugger event