Repository files navigation

avoid pitfalls when async iterating a ReadableStream

Long-lived promises are dangerous. At JCore Systems, we have a lot of places we wrap pubsub in async iterables orReadableStreams. This means we're creatingpromises that can be indefinitely pending until the next pubsub event comes in.

It's extremely easy to cause memory and resource leaks with long-lived promises like this. Even if you usePromise.race([resultPromise, abortPromise(signal)])to make sure a next event promise rejects right away if you abort a signal,it still leaks memory. The handlersthat were waiting on the promise are still retained as long asresultPromise is pending, even after the other promise rejects.

To complicate matters withReadableStreams, the builtinReadableStream[Symbol.asyncIterator] implementation doesn't cancel the stream right away when the iteratorisreturn()ed if the lastnext() promise is still pending because the underlying read is waiting. If the read doesn't resolve until a pubsub event comes in,the stream could be stuck open for an unbounded amount of time.

To avoid this danger, you have to either write the underlying operations to time out after a maximum amount of time (which still delays cleanup temporarily) oruse use carefully-written logic like@jcoreio/safe-iterate-readable-stream provides to guarantee timely cleanup when async operations are aborted.

Returns anAsyncIterable that iterates over the given stream. If the iterator isreturn()ed,throw()n, orsignal is aborted, it will close and rejectany outstandingnext() promises immediately.

import{safeIterateReadableStream}from'@jcoreio/safe-iterate-readable-stream'conststream=newReadableStream({ ...})constabortController=newAbortController()const{ signal}=abortControllerforawait(constchunkofsafeIterateReadableStream(stream,signal)){console.log(chunk)}