UnhandledPromiseRejectionWarning: TypeError: reader._closedPromise_resolve is not a function

[RangerMauve]

Hi, I'm getting an unhandled error even though it seems to be working otherwise.

``` (node:102333) UnhandledPromiseRejectionWarning: TypeError: reader._closedPromise_resolve is not a function at defaultReaderClosedPromiseResolve (/home/mauve/programming/make-fetch/node_modules/web-streams-polyfill/dist/ponyfill.es6.js:261:16) at ReadableStreamClose (/home/mauve/programming/make-fetch/node_modules/web-streams-polyfill/dist/ponyfill.es6.js:3092:9) at ReadableStreamDefaultControllerClose (/home/mauve/programming/make-fetch/node_modules/web-streams-polyfill/dist/ponyfill.es6.js:2616:13) at /home/mauve/programming/make-fetch/node_modules/web-streams-polyfill/dist/ponyfill.es6.js:3527:13 at processTicksAndRejections (internal/process/task_queues.js:97:5) (node:102333) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1) (node:102333) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. ```

This is happening with version 3.0.0 installed from NPM on Node v12.16.2

[MattiasBuelens]

That's odd... that shouldn't happen. Thanks for reporting.

Do you have a way to reproduce this problem? A code snippet that I can run, or a repository that I can clone?

[RangerMauve]

Thanks for the quick response.

It's happening in my tests in make-fetch

• git clone [email protected]:RangerMauve/make-fetch.git
• cd make-fetch
• Get rid of the try-catch wrappr on this line
• npm i
• npm test

[MattiasBuelens]

I managed to reproduce it locally right away. Thanks for the very clear reproduction case! 😄

When the readable stream closes (through ReadableStreamClose), it calls the close steps of the pending read request of the async iterator, which releases the lock. This rejects the reader's closed promise, which also clears its resolve and reject callbacks. However, ReadableStreamClose then tries to resolve that same reader's closed promise, which fails because we already cleared those callbacks.

The polyfill assumes that we'll only ever try to resolve or reject the closed promise once. However, the specification doesn't seem to guarantee that, and your example shows that. So this assumption is incorrect, and the polyfill needs to handle this case. I'll work on a fix as soon as possible. 😉

On a slightly unrelated note: I also noticed that, although the closed promise was still pending, ReadableStreamReaderGenericRelease still created a new closed promise instead of rejecting the existing one. This is because ReadableStreamClose had already set the stream's state to "closed" before calling the close steps, which in turn call ReadableStreamReaderGenericRelease. I'll investigate the impact of this a bit further, since this might need a spec change. 🕵️‍♂️

[RangerMauve]

Jeeze, sounds pretty complex. Hopefully this'll help others in the future.

Is there anything I should do on my end of the code in the meantime? I'm fine with leaving my try-catch hack in there for now.

Thank you for investigating!

[MattiasBuelens]

It's quite complex, yes. I'm actually amazed something as complicated as this can be triggered with very little code. 😅

Your try-catch hack should be fine for now. Hopefully you'll be able to remove it after the next patch release. 😄