Re: [whatwg/streams] Settle reader.[[closedPromise]] before performing close/error steps of read requests (#1102)

> I kind of thought in this scenario the double-resolve was unavoidable, so the assert would fail? But I guess I missed something.

Nope.

At the start of `ReadableStreamClose`, the stream is still `"readable"`. So if it is locked to a reader, that reader's `[[closedPromise]]` is still pending. Originally, we would first change the state to `"closed"`, then run the close steps of all read requests, and *only then* resolve `[[closedPromise]]`. We assumed that `[[closedPromise]]` cannot be changed by those close steps, and thus is still pending when we try to resolve it. This was incorrect: if one of those close steps calls `ReadableStreamGenericRelease`, `[[closedPromise]]` will have been *replaced* with a rejected promise, and we'd be resolving an already rejected promise.

We now swap the order around: first change the state to `"closed"`, resolve `[[closedPromise]]`, and then run the close steps. The close steps are still the same: `ReadableStreamGenericRelease` will still replace the (now resolved instead of pending) `[[closedPromise]]` with a rejected promise. But we don't need to do anything else *afterwards* in `ReadableStreamClose`, so we no longer need to worry about what those close steps might have changed. 😉

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/pull/1102#issuecomment-774716216