- From: Mattias Buelens <notifications@github.com>
- Date: Thu, 27 Jan 2022 13:08:59 -0800
- To: whatwg/streams <streams@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/streams/pull/1208/review/865430270@github.com>
@MattiasBuelens commented on this pull request. > @@ -475,6 +483,20 @@ function WritableStreamDefaultWriterGetDesiredSize(writer) { return WritableStreamDefaultControllerGetDesiredSize(stream._controller); } +function WritableStreamDefaultWriterIsOrBecomesErrored(writer, errorListener) { Coming back to this: > Adding `await flushAsyncEvents()` before calling `pipeTo()` in that test restores the order and fixes the problem. Good enough? 🤷♂️ It seems the main difference is that, when you call `readable.cancel()`, we *always* synchronously call `source.cancel()` regardless of whether `source.start()` has already settled. On the other hand, when you call `writable.abort()`, we first wait for `sink.start()` to settle before we call `sink.abort()`. IIRC the reason for this difference is so you can do e.g. an async loop in `source.start()`: ```javascript new ReadableStream({ async start(c) { for (let i = 0; i < 10; i++) { await new Promise(r => setTimeout(r, 1000)); c.enqueue("chunk"); } c.close(); } }) ``` whereas for `sink.start()` this doesn't make sense. I guess, if we *really* wanted to, we could have the test check when `writableController.signal` becomes aborted? That should happen synchronously *regardless* of whether `sink.start()` has already settled. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/streams/pull/1208#discussion_r794000293 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/streams/pull/1208/review/865430270@github.com>
Received on Thursday, 27 January 2022 21:09:12 UTC