Re: [whatwg/streams] add @@asyncIterator to ReadableStream (#954)

Let's work on a test plan together to guide @devsnek. Here's a start:

- Basic test of a stream with a few chunks that closes
    - Using a "push" underlying source (calls `c.enqueue()` in `start`) that enqueues all at once
    - Using a "push" underlying source  where you call `c.enqueue()` "just in time" (i.e. inside the loop body)
    - Using a "pull" underlying source (calls `c.enqueue()` in `pull`) using recordingReadableStream to verify the correct underlying source method calls
- Degenerate streams
  - Async-iterating an errored stream throws
  - Async-iterating a closed stream never executes the loop body, but works fine
  - Async-iterating an empty but not closed/errored stream never executes the loop body and stalls the async function (end the test if 50 ms pass without the promise resolving)
- `@@asyncIterator()` method is `===` to `getIterator()` method
- Cancelation behavior (use recordingReadableStream)
  - Manually calling `return()` causes a cancel
  - `throw`ing inside the loop body causes a cancel
  - `break`ing inside the loop body causes a cancel
  - `return`ing inside the loop body causes a cancel
  - All of the above, but with `preventCancel: true` and the pass conditions reversed
- Manual manipulation
  - double-return rejects (https://github.com/whatwg/streams/pull/954#discussion_r216237031)
  - next()'s fulfillment values have exactly the right shape (Object.prototype, only two properties, correct property descriptors)
  - throw method does not exist
  - Calling next() or return() on non-ReadableStreamDefaultReaderAsyncIterator instances rejects with TypeError (there are existing brand check tests you can add to)
  - Calling return() while there are pending reads (i.e. unsettled promises returned by next()) rejects the return Promise (https://github.com/whatwg/streams/pull/950#issuecomment-417393457)
- Interaction with existing infrastructure
  - getIterator/@@asyncIterator throw if there's already a lock
  - Monkey-patch getReader and default reader's prototype methods and ensure this does not interfere with async iteration (e.g. using one of the basic test cases)
  - Basic test with a few chunks but you've already consumed one or two via a normal reader (which you then released)
- Auto-release
  - You can still acquire a reader and successfully use its `.closed` promise after exhausting the async iterator via for-await-of
  - You can still acquire a reader and successfully use its `.closed` promise after `return()`ing from the async iterator (either manually or via `break`; take your pick)

Can anyone think of something else that might be missing?

-- 
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/954#issuecomment-421107013