parallel/test-debugger-run-after-quit-restart is flaky on macOS

[mcollina]

Flaky Test: parallel/test-debugger-run-after-quit-restart

Platform: macOS

Failed run: https://github.com/nodejs/node/actions/runs/27749999537/job/82367922179?pr=63973

Error:

=== 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.

[inoway46]

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 ... 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:

node/lib/internal/debugger/inspect_repl.js

Lines 913 to 921 in 81e93df

	inspector.suspendReplWhile(() =>
	PromisePrototypeThen(
	SafePromiseAllReturnArrayLike([formatWatchers(true), selectedFrame.list(contextLineNumber)]),
	({ 0: watcherList, 1: context }) => {
	const breakContext = watcherList ?
	`${watcherList}\n${inspect(context)}` :
	inspect(context);
	print(`${header}\n${breakContext}`);
	}));

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

return Runtime.runIfWaitingForDebugger();

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.