p-map

On current (), subscribes to an async iterator's custom thenable once to observe , then returns the original thenable for the caller to await. A cold thenable therefore runs twice per , which can silently consume and discard items. Minimal reproduction from a current checkout: The same failure affects and both ordering modes. The existing thenable test captures a fixed result before runs, so subscribing twice does not expose the problem there. Tested two-file patch: normalize each async pull with before observing/awaiting it; preserve the synchronous iterator fast path. No preliminary read, so a getter is also read once. Validation on native Windows Node 24.14.1 and Linux Node 24.19.0: all eight new regression cases fail against unchanged main, and the patched full suite passes 418 tests plus XO and tsd on both. This is not the full Node-version CI matrix or a performance claim. PR creation is collaborators-only, so I am sharing the reproduction and patch here. AI-assisted; I inspected the implementation and ran the native comparisons above.

Fixes #34 It's opt-in since it does come with a tiny performance overhead. From a lot of research, this is the only way I managed to preserve the stack trace.

Both, and don't show the stack-trace beyond the point p-map got called. In other words, the functions that called before pMap, disappear from the stack trace. As a comparison, the p-map-series doesn't suffer from this issue. It does keep the stack-trace. See the example below, if you run a function that runs the native , the stack trace shows the function name - . Same if you run the function . However, try to run , and you'll see how the stack trace truncated. I tried node v12.x and v14.x. Results when running : Results when running .