p-limit

When an input iterator throws after yielding an item, rejects with the iterator error but leaves already scheduled mapper promises unobserved. If a mapper also rejects, Node terminates with an unhandled rejection even though the caller caught the map error. Reproduced with p-limit 7.3.0, 7.3.2, and main at , using Node 24.13.0 on macOS. Reproduction With p-limit 7.3.2 installed, save this as and run : Actual: prints , then exits with code 1 from an unhandled rejection. Replacing with is a healthy control: the catch receives and the process exits cleanly. Expected: the iterator error rejects the returned promise, while rejections from tasks already scheduled by are observed. This need not cancel those tasks or delay the iterator error until they finish. Cause and proposed fix schedules mapper promises while consuming the iterator. If iteration throws, execution never reaches , leaving those promises unobserved. I recognize that the documented equivalent expression currently has this same behavior; this is a proposal to harden that failure path. A tested candidate fix records scheduled promises during iteration and observes them with in the iteration-error path before immediately rethrowing the original error. It preserves scheduling order, shared-queue behavior, and array-like runtime support. It adds a temporary array of promise references during collection. Verification: two strict subprocess regressions fail against unchanged main; all 30 tests pass with the fix on Node 22.20.0 and 24.13.0. Full , including XO and tsd, passes on Node 24 (one existing TODO warning). Controls cover throwing before any item, mapper errors, interleaved scheduling, array-like input, and immediate rejection with pending work. Node 20 and browsers were not tested locally. I found no exact duplicate in the open and closed reports checked. GitHub denied pull-request creation for my account, so I am sharing the reproduction and candidate commit here. Prepared with OpenAI Codex assistance.

Problem accepts and documents , but the returned function does not expose . Callers therefore cannot trigger the promised rejection behavior, and attempting to do so throws . Fix Expose the internal limiter's existing method on the returned limited function, reflect it in the TypeScript return type, and document the method. This reuses the established queue-clearing behavior without changing scheduling or call signatures. Tests — passed (1 test) — passed — passed (23 AVA tests; one pre-existing XO TODO warning) — passed Compatibility This adds a non-enumerable method to functions returned by . Existing calls and concurrency behavior are unchanged; clearing delegates to the internal limiter's existing semantics. Related issue No linked issue. Reproduced on at ; live issue/PR and focused duplicate searches found no competing work.

Summary make use the limiter it belongs to instead of its call-time receiver cover detached calls sharing the limiter's configured concurrency with direct tasks Problem is exposed as a callable function property, but its implementation invokes the limiter through dynamic . A valid detached call such as therefore rejects with . Fix Use the closed-over function when scheduling mapped items. This preserves the existing concurrency, ordering, iterable, and index behavior without requiring a bound receiver. The regression test combines a direct limiter call with a detached call and verifies their shared maximum concurrency remains at the configured limit. Testing AVA suite on Node.js 20, 22, and 24 The aggregate command was also attempted. On this Windows checkout, XO reports its existing TypeScript project-service lookup error for and ; the same error occurs on the untouched base. The changed JavaScript files pass XO.