-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
Description
Is your feature request related to a problem? Please describe.
The current async-iterator on Readable
streams always destroys the stream, when you break or return or an error is thrown. Specifically, this means that if someone wants to iterate over the same stream in different places (for example iterate until the end of part one... then do some things, continue iterating later etc) this is impossible - you have to have exactly one for await...of that you work inside of. In addition, there are other scenarios like Request
where iterating over the request ends up closing the response (which might specifically be a bug in the Request iterator, and not really related to destroying the request) and this suggestion would allow bypassing it for other use-cases without adding special specific use-case code (I'm not sure if this is an issue with Duplex
streams in general?).
Describe the solution you'd like
I'd like to create another async-iterator (in addition to the existing one) that would give users the option opt in/out of destroying the stream non-error ending of the iteration (any maybe also on stream-error?). The naming could be very explicit, to let users know that they've decided to opt-out of the default behavior, or if an explicit name is not required just added as parameters to the Symbol.asyncIterator
method.
Something like this (I haven't thought a lot about the naming):
for await (const chunk of readable.nonDestroyingIterator({ destroyOnError: true, destroyOnReturn: false}) {
}
Looking around createAsyncIterator
in readable.js
, this wouldn't be too difficult to add, and I would be happy to provide a PR for this.
Describe alternatives you've considered
Building another iterator myself on existing streams.