Allow error to be provided to reader.releaseLock()

[jakearchibald]

What problem are you trying to solve?

I have a pending reader.read(), but at some point I'm no longer interested in the result, so I call reader.releaseLock(), allowing for another reader to come along later.

This rejects reader.read() with a TypeError, which is indistinguishable from other kinds of 'worse' errors.

I'd rather it rejected with something like an AbortError, as failure is expected in this case.

What solutions exist today?

I guess setting some boolean when I call releaseLock(), so I know to ignore the error, then just hope the error wasn't relating to something else.

How would you solve it?

I guess reader.releaseLock(reason).

Anything else?

No response

[MattiasBuelens]

I suppose it makes sense that releaseLock(reason) would mirror AbortController.abort(reason). Unfortunately, I think reason will still default to a TypeError for backwards compatibility, so you have to bring your own AbortError if you want that. 😅

Would you expect reader.closed to reject with the same reason that was passed to releaseLock()? Right now, reader.closed always rejects with a fresh TypeError as per steps 4 and 5 of ReadableStreamReaderGenericRelease, but I think we should use the same reason.

[jakearchibald]

Yeah, using the same reason for .closed makes sense.

[0f-0b]

What about making this error a subclass of TypeError, just like how QuotaExceededError was recently changed to be a subclass of DOMException? Subclassing allows for extra information to be included, which in this case is the fact that the error is produced by releaseLock.

[saschanaz]

How do we tell the abort is from stream abort or the reader abort? 🤔