-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standardizing ".destroy()" #124
Comments
FWIW: in WHATWG streams, we have |
I think an overridable myStream._destroy = function (cb) {
closeResources(function (err) {
cb(err)
})
}
myStream.destroy() // calls the above method
myStream.destroy() // doesn't do anything |
+1! I always end up bike-shedding my own |
@domenic I'd definitely be interested in why prematurely ending a writable implies an error. @mafintosh So, to make sure I've got this correct, a few of the potential event sequences are:
|
@chrisdickinson there's like three things you can do:
|
@chrisdickinson the scenarios look right to me! at some point we should consider if .pipe should return to streams1 behavior and call .destroy on close as well (but that should be a different issue) |
@domenic Ah, cool. That makes sense. Do errors travel up pipelines? (i.e., would something like |
@chrisdickinson yeah piping by default propagates errors backward and forward. If |
@domenic Ooh, jealous. :) @mafintosh Cool. Starting to collect
|
I'm +1. awesome ascii flow diagrams @chrisdickinson I think it is possible to have a method of propagating this kind of stream state up and down the pipeline that would be awesome too. At the moment the amount if error handling needed to properly prevent against potential leaks and errors is quite verbose and easily overlooked from the slick stream Interestingly |
This is being worked on in nodejs/node#12925. |
This has landed 🎉 ! |
landed and will be in 8.0.0 |
@chrisdickinson Unrelated* what did you use to generate this? Looking for something similar. |
This is a behavior that streams used to have (as of streams 1), but was never really fully specified, and was removed in streams2+. The result is that there's no standard way to prematurely end a stream from the outside, and the effects of prematurely ended streams are undefined (or surprising to our users).
@mafintosh may have more words about this!
The text was updated successfully, but these errors were encountered: