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
parallel/test-debugger-run-after-quit-restart is flaky on macOS #64005
=== release test-debugger-run-after-quit-restart ===
Path: parallel/test-debugger-run-after-quit-restart
Error: --- stderr ---
/Users/runner/work/node/node/node/test/common/debugger.js:92
const timeoutErr = new Error(`Timeout (${TIMEOUT}) while waiting for ${pattern}`);
^
Error: Timeout (15000) while waiting for /break (?:on start )?in/i
at /Users/runner/work/node/node/node/test/common/debugger.js:92:28
at new Promise (<anonymous>)
at Object.waitFor (/Users/runner/work/node/node/node/test/common/debugger.js:67:14)
at Object.waitForInitialBreak (/Users/runner/work/node/node/node/test/common/debugger.js:116:18)
at /Users/runner/work/node/node/node/test/parallel/test-debugger-run-after-quit-restart.js:63:21
at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
Output:
< Debugger ending on ws://127.0.0.1:55271/62ec7a96-161d-43d4-8299-2c22fbd386d9
< For help, see: https://nodejs.org/learn/getting-started/debugging
<
debug>
< Debugger listening on ws://127.0.0.1:55280/8741a480-0ae2-47ad-90c6-72c2e4dae019
< For help, see: https://nodejs.org/learn/getting-started/debugging
<
debug> connecting to 127.0.0.1:55280 ... ok
< Debugger attached.
<
debug>
debug>
Root cause: The debugger inspector round-trip can be slow under CI load on macOS, causing the 15s timeout to be exceeded when waiting for the initial break after restart.
The new logs already include connecting ... ok and Debugger attached., so the test has passed the reconnect / ok synchronization point.
One remaining weak spot seems to be the gap between Runtime.runIfWaitingForDebugger() and the CLI actually printing the initial break ... in ... output. The Debugger.paused handler first awaits the async pause formatting path, including selectedFrame.list(contextLineNumber) / Debugger.getScriptSource, and only then prints the break line:
So the next fix direction might be to make run / restart resolve only after the initial pause output has been displayed. I tried a local prototype of that approach and the relevant debugger tests pass locally.
That said, this changes node inspect command-completion semantics rather than only the test, so it would be good to confirm whether that behavior is desired. Is this direction reasonable? (cc: @mcollina@trivikr)
I can help test/review or share details from the local prototype.
Update: Based on #65194 and the subsequent stress results, run-after-quit-restart failure now appears more likely to have been caused by Runtime.runIfWaitingForDebugger() being sent before the target entered its frontend wait.
The render-order gap described in #64005 (comment) is still valid, but it should be treated as a separate follow-up rather than the primary cause of this flake.
Activity
inoway46 commentedon Jun 20, 2026
Thanks for opening the issue. I took look at the failure logs. I don't think this is the same race fixed by #62807.
(another log: https://github.com/nodejs/node/actions/runs/27702868250)
The new logs already include
connecting ... okandDebugger attached., so the test has passed the reconnect /oksynchronization point.One remaining weak spot seems to be the gap between
Runtime.runIfWaitingForDebugger()and the CLI actually printing the initialbreak ... in ...output. TheDebugger.pausedhandler first awaits the async pause formatting path, includingselectedFrame.list(contextLineNumber)/Debugger.getScriptSource, and only then prints the break line:node/lib/internal/debugger/inspect_repl.js
Lines 913 to 921 in 81e93df
Runtime.runIfWaitingForDebugger()is awaited here, but that does not appear to wait for the paused-event output formatting to complete:node/lib/internal/debugger/inspect_repl.js
Line 1197 in 81e93df
So the next fix direction might be to make
run/restartresolve only after the initial pause output has been displayed. I tried a local prototype of that approach and the relevant debugger tests pass locally.That said, this changes
node inspectcommand-completion semantics rather than only the test, so it would be good to confirm whether that behavior is desired. Is this direction reasonable? (cc: @mcollina @trivikr)I can help test/review or share details from the local prototype.
test: mark test-debugger-run-after-quit-restart as flaky on macOS
test: mark test-debugger-run-after-quit-restart as flaky on macOS
test: mark test-debugger-run-after-quit-restart as flaky on macOS
test: mark test-debugger-run-after-quit-restart as flaky on macOS
test: mark test-debugger-run-after-quit-restart as flaky on macOS
test: mark test-debugger-run-after-quit-restart as flaky on macOS
test: mark test-debugger-run-after-quit-restart as flaky on macOS
inoway46 commentedon Aug 15, 2026
Update: Based on #65194 and the subsequent stress results,
run-after-quit-restartfailure now appears more likely to have been caused byRuntime.runIfWaitingForDebugger()being sent before the target entered its frontend wait.The render-order gap described in #64005 (comment) is still valid, but it should be treated as a separate follow-up rather than the primary cause of this flake.
inoway46 commentedon Aug 16, 2026
I also ran
run-after-quit-restart1,000 times with-j16on macOS 15:This provides further evidence that #65194 may also fix this flake.
test: remove test-debugger-run-after-quit-restart as flaky on macOS
test: remove test-debugger-run-after-quit-restart as flaky on macOS
test: remove test-debugger-run-after-quit-restart as flaky on macOS
test: remove test-debugger-run-after-quit-restart as flaky on macOS
test: remove test-debugger-run-after-quit-restart as flaky on macOS
test: remove test-debugger-run-after-quit-restart as flaky on macOS