p-wait-for

A timeout during the initial delay () rejects directly with the native reason. It never goes through the library's timeout handling, so the configured fallback, custom error, and exported type are lost. Reproduced on Node.js v22.23.3 against main at (package version 6.0.0). Expected: resolves to , with one fallback call and no condition calls. Actual: Replacing the fallback with also loses the supplied error and rejects with the native timeout reason instead. With , the fallback works. The initial sits outside the that calls . Routing that initial sleep's abort rejection through the same handler fixes the focused regression in a local probe. I did not run the full project suite.

The wait remains pending after an abort or timeout if the current condition has not settled. If that condition later returns , the wait succeeds even though it was already aborted. A condition that never settles makes the timeout ineffective indefinitely. Reproduced on Node.js v22.23.3 against main at (package version 6.0.0). The same issue affects : replacing the signal option with and racing against a 50 ms delay still prints . Resolving the condition to then fulfills the wait rather than rejecting with . The operation awaits directly; the combined signal is observed only before the loop or during sleeps between checks. Cancellation needs to be able to settle the outer wait while the condition is pending. This does not require cancelling the condition's underlying work, but its eventual fulfillment/rejection still needs a handler. The existing test named returns after a delay, so it reaches another sleep and does not cover an indefinitely pending condition or a late result. Related to the older closed #27, but this reproduction concerns the returned promise not settling at its deadline, rather than polling continuing after rejection. I ran focused abort and timeout regressions locally; both fail on this checkout. I did not run the full project suite. No PR attached.

Each completed sleep retains its abort listener on the user-supplied signal. After polling succeeds, those listeners remain attached. Reusing a long-lived signal across polling operations makes them accumulate. Reproduced on Node.js v22.23.3 against main at (package version 6.0.0), without a finite timeout: Expected: . Actual: . Repeating the operation with the same signal adds another 19 listeners each time. The signal retains the completed sleep closures and their timeout/rejection state until it aborts or becomes unreachable. removes the listener only when an abort occurs, not when the timer resolves normally. Removing the named abort handler in the normal timeout callback fixes the focused regression in a local probe. The existing abort path can still clear the timer and reject as before. I did not run the full project suite.