Re: [whatwg/streams] ReadableStreamClose with async iterator and pending read requests errors (#1100)

I tried digging in to this a bit, but I'm still not sure I've got this all loaded into my head correctly... please let me know if I'm off base on any of the following.

> Although we would still reject both the read() and closed promises in ReadableStreamClose, the relative order of these rejections would change.

From what I can tell, ReadableStreamClose resolves the reader's [[closedPromise]] with undefined, and sets the [[state]] to "closed". So then the loop would repace [[closedPromise]] with a new rejected promise, I think. Is that what you mean?

More generally, I'm wondering if this problem is reproducible outside the framework of async iterators. Isn't something like the following very similar?

```js
reader.read(({ value, done }) => {
  if (done) {
    reader.releaseLock();
  }
});
```

I guess that one is saved by the extra microtask delay, which effectively makes the release call happen after the state has already become "closed"?

If that's the case, then maybe rearranging the steps would be better, so that the async iterator close steps behave similarly to such a code snippet...

And also just from a general code hygeine perspective, ReadableStreamClose does look a little weird: it should probably keep [[state]] setting closer to [[closedPromise]] setting, without the arbitrary spec code of the close steps running in between.

-- 
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/issues/1100#issuecomment-761249776