Re: [whatwg/streams] Cancelling and exception handling async iteration of ReadableStreams (Issue #1255)

> Putting it around the function `logChunks()` that does the iteration does not work - any thoughts why (hope this is not some blindingly obvious JavaScript thing.

This might be a silly question, but are you `await`ing the result of `logChunks()`? That is:
```js
try {
  await logChunks();
} catch (error) {
  console.error("Oh no!");
}
```
Because if you don't `await` it, then the returned promise won't be used and you'll (at best) get an unhandled promise rejection in the console.

> I am pretty sure we designed Web IDL's async iterator machinery this way, to make it follow JavaScript async generators.

Right, of course, I should have compared with async *generators*. 😅 I suppose we can't depart from those semantics.

How do we feel about adding an `AbortSignal` in the mix? 🤔 We could add an abort algorithm that is pretty much the same as our [asynchronous iterator return](https://streams.spec.whatwg.org/#rs-asynciterator) steps, except that we don't assert that `[[readRequests]]` is empty (which is no longer necessary as of #1168).

However, I'm a bit worried about how that would compose. Would the proposed `ReadableStream.from()` method need to accept an optional `AbortController` argument, so it can early-abort the given async iterator on `cancel()`?
```js
const readable1 = new ReadableStream({ /* ... */ });
const controller = new AbortController();
const iterator = readable1.values({ signal: controller.signal });
const readable2 = ReadableStream.from(iterator, { controller });
// readable2 behaves like readable1, and cancelling readable2 immediately cancels readable1
```

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1255#issuecomment-1431470151

You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/issues/1255/1431470151@github.com>