Promise rejection in timeout (versus module-level) treated as unhandled by debugger

### Version v22.4.0 ### Platform ```text Darwin Hypothesis.local 24.0.0 Darwin Kernel Version 24.0.0: Thu Jun 20 20:36:19 PDT 2024; root:xnu-11215.0.115.501.3~1/RELEASE_ARM64_T8103 arm64 ``` ### Subsystem _No response_ ### What steps will reproduce the bug? Create this script: ```js setTimeout(() => { Promise.reject().catch(() => { }) }, 1) ``` And run it in the debugger with `break on Uncaught` enabled. ### How often does it reproduce? Is there a required condition? Every time. Note this does *not* happen if `Promise.reject()` is at top level instead of wrapped in `setTimeout()`. ### What is the expected behavior? Why is that the expected behavior? It is expected that the debugger does (1) not pause on such a promise or (2) only pauses on such a promise if `breakOnException` is enabled. The [HTML spec](https://html.spec.whatwg.org/multipage/webappapis.html#unhandled-promise-rejections) guarantees that promise rejections are *not* considered unhandled if a handler is then synchronously attached. ### What do you see instead? Node breaks synchronously on the creation of the rejected promise. Similar issues happen when using the VSCode debugger and Chrome debugger. ``` node inspect promisetest.js < Debugger listening on ws://127.0.0.1:9229/d18cff1f-6886-4ff6-9a4f-404128bd150a < For help, see: https://nodejs.org/en/docs/inspector < < Debugger attached. < ok Break on start in promisetest.js:1 > 1 setTimeout(() => { 2 Promise.reject().catch(() => { }) 3 }, 1) debug> breakOnUncaught debug> c promiseRejection in promisetest.js:2 1 setTimeout(() => { > 2 Promise.reject().catch(() => { }) 3 }, 1) 4 ``` ### Additional information A downstream issue where this interferes with usage of the web streams API: #51093 I too have been incredibly confused by this, as it makes it seem like even *correct* usage of promises is developer error. VSCode reports this as "Exception has occurred" instead of "promiseRejection".