Mattias Buelens

We've run into this problem as well. It seems to only happen with empty files (0 bytes), but we've only seen it happen occasionally on our CI. I suspect there's...

@essential-existence I suggest you open a separate issue for that. This issue is about implementing a *change* to `releaseLock()`. That said, I am a bit curious. That error appears as...

> Probably also want to consider an equivalent API where the buffer is already allocated (similar to `encodeInto()`, BYOB). I like the idea of a method that fills up an...

> > Should we also have a shorthand `ReadableStream.readFully(view)`? > > IMO we should only do that if we do #1072. Sure! 🙂 > > Would it have the same...

It shouldn't be that difficult. Currently #1145 works by adding a *fill* boolean flag to each pull-into descriptor to decide if it should fill up to at least *element size*...

`minBytes` might not be the best name if you're reading into a multi-byte typed array, since you want to reason about `view.length` instead of `view.byteLength`. Maybe `atLeast` works better? ```javascript...

> Is this going to be accompanied with a timeout parameter or abort signal? There's a separate discussion ongoing to make reads abortable in #1103. Combined with whatwg/dom#951, you could...

We ended up with a slightly different approach for #1103. Instead of adding a new API that accepts an `AbortSignal`, we changed the behavior of `reader.releaseLock()`. So the above example...

> Should we make unbuffered transforms the default? I suspect it's more desirable, and hopefully wouldn't be _too_ breaking... I'd like that *a lot*. * Identity transform streams would no...

Hmm, good point. We don't know if or when `transform()` will call `enqueue()`. It might do it synchronously (e.g. for an identity transform or for `TextDecoderStream`), in which case buffering...