debugger: defer probe pause handling until startup

[trivikr]

Fixes a race in debugger probe mode where the startup --inspect-brk
pause could be resumed before probe breakpoints were fully installed.

The generic Debugger.paused handler resumes pauses that do not match a
probe breakpoint. During startup, that can include the initial --inspect-brk pause.
If it is resumed before bindBreakpoints() finishes, a short target script can run
past the probe location and the probe session times out.

This change ignores pause events until probe startup has completed, so the
main setup flow remains responsible for releasing the target after
breakpoints are bound.

Refs: https://github.com/nodejs/node/actions/runs/26482141780/job/77981519238

Error Log

=== release test-debugger-probe-no-column-indent ===Path: parallel/test-debugger-probe-no-column-indentError: --- stderr ---[process 40660]: --- stderr ---[process 40660]: --- stdout ---{"v":2,"probes":[{"expr":"x","target":{"suffix":"probe-indented.js","line":6}}],"results":[{"event":"timeout","pending":[0],"error":{"code":"probe_timeout","message":"Timed out after 30000ms waiting for probes: probe-indented.js:6"}}]}[process 40660]: status = 1, signal = null/Users/runner/work/node/node/dir%20with $unusual"chars?'åß∂ƒ©∆¬…`/test/common/child_process.js:112 throw error; ^Error: - process terminated with status 1, expected 0 at Object.<anonymous> (/Users/runner/work/node/node/dir%20with $unusual"chars?'åß∂ƒ©∆¬…`/test/parallel/test-debugger-probe-no-column-indent.js:14:1) at Module._compile (node:internal/modules/cjs/loader:1879:14) at Object..js (node:internal/modules/cjs/loader:2019:10) at Module.load (node:internal/modules/cjs/loader:1602:32) at Module._load (node:internal/modules/cjs/loader:1404:12) at wrapModuleLoad (node:internal/modules/cjs/loader:255:19) at Module.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:154:5) at node:internal/main/run_main_module:33:47 { options: { cwd: '/Users/runner/work/node/node/dir%20with $unusual"chars?\'åß∂ƒ©∆¬…`/test/fixtures/debugger' }, command: '/Users/runner/work/node/node/dir%20with $unusual"chars?\'åß∂ƒ©∆¬…`/out/Release/node inspect --json --probe probe-indented.js:6 --expr x probe-indented.js'}

---

Assisted-by: openai:gpt-5.5

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.31%. Comparing base (d8ac301) to head (6195187).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #63608 +/- ##
==========================================
- Coverage 90.31% 90.31% -0.01% 
==========================================
Files 730 730 Lines 234695 234711 +16 Branches 43966 43959 -7 ==========================================
+ Hits 211972 211986 +14 - Misses 14432 14449 +17 + Partials 8291 8276 -15 

Files with missing lines	Coverage Δ
lib/internal/debugger/inspect_probe.js	79.93% <100.00%> (-0.03%)	⬇️

... and 43 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[watilde]

LGTM, thanks for chasing this down. All test-debugger-probe-* pass locally with no hangs.

One non-blocking note on the comment: on Linux (NODE_DEBUG=inspect_probe) I see the Break on start pause arrive after runIfWaitingForDebugger, released by Debugger.resume — so runIfWaitingForDebugger triggers that pause rather than releasing it. And since started = true is set just before that call, the guard never actually holds the pause in this ordering (confirmed with the patch applied).

Could be the timing differs on the failing platform (macOS arm64) if you happen to have a NODE_DEBUG=inspect_probe trace from a repro, it'd be good to confirm the guard is catching the startup pause there. Either way the change is safe, so feel free to land; just maybe tweak the comment wording if the release path turns out different.

[trivikr]

Thank you @watilde for review and feedback.

The comment was updated in 0917b58 (this PR), and I've requested a new review.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/74224/

[nodejs-github-bot]

Landed in 1a33a8c

[joyeecheung]

I don't think the stated scenario can actually happen, and the change can make the behavior worse:

1. this.started is only set to trueafterawait this.bindBreakpoints(), and the target is only released by Runtime.runIfWaitingForDebugger()after that. So no pause (not even the --inspect-brk break-on-start) can realistically arrive while !this.started - as pointed out in debugger: defer probe pause handling until startup #63608 (review) the break-on-start is delivered only after runIfWaitingForDebugger, by which point started is already true and the existing if (hitBreakpoints === undefined || hitBreakpoints.length === 0) path already resumes it. The test only reaches the guarded state by manipulating internals to fabricate a state that's unreachable from probe mode in the real world.
2. If in the future we implement attaching to a process that already has breakpoints, the previous code would resume if the breakpoint is not part of the probed ones, which is good. The changes here would actually make that hang without resuming, which would be undesirable.

Have you verified, without manipulating internals, that this actually fixes the flake in GitHub Actions? From the logs this looks like another reproduction of #63632 (comment), which predates probe mode - the interactive-mode tests are still hanging a lot from the same cause in CI, so I doubt changing probe mode fixes anything here.