-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
[x] stream: don't emit finish after destroy() #29205
Conversation
7673bdd
to
d18961a
Compare
When reviewing please look at each commit, otherwise it's difficult to fully follow the changes. |
d18961a
to
11c1620
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Unchecking test. Seems there are some failures I missed. Probably need to update tests to consider the new behavior. |
When destroying the stream will be potentially incomplete and therefore it doesn't make sense to emit finish.
d4602d4
to
b8f013a
Compare
Rebased and test fixed. |
bc067c0
to
b8f013a
Compare
b8f013a
to
1107841
Compare
@mcollina: This required more significant changes to pass all test. Mainly in relation to |
@lpinca: How? |
1107841
to
c7a82fb
Compare
Yes but I think it goes against the original intent of d3f02d0? At least this is what it seems to me by looking at the changes made to The proposed change to not emit |
Yeah, I see that there could be arguments made for either behaviour. I’m not sure why we wouldn’t emit |
Because it's unexpected? e.g. foo.on('continue', () => {
// more followup side effects...
})
s.on('finish', () => {
foo.emit( 'continue')
});
foo.on('cancelled', () => {
foo.destroy()
foo.on('continue', mustNotCall())
}); As a user I wouldn't want finish to be emitted if I destroy the stream, I would expect destroy is aborting any following side effects as well. I would not expect to have to remove my finish listener. |
I don’t really see why it’s unexpected – yes, you need to be aware of whether the stream was destroyed, but in the In the end, it’s not that important to me – you can go ahead with this, and as long as it’s landed in a major release, I don’t think this is a huge issue. |
c7a82fb
to
73048fa
Compare
73048fa
to
8add970
Compare
Hmm... I'm not convinced just yet. If I'd be much happier with that kind of approach than this semver-major change. |
Yep, I asked something similar to be added for the TSC agenda today/tomorrow (#29197).
Currently we do not have any well defined semantics to achieve both at the same time... Would probably have to add more state to the streams or maybe we could use My opinion is that My assumption so far based on the rest of the code and also the documentation has been that after If we compare with rxjs observables or other stream similar library. If I dispose an observable, it will not call my complete function, even if the observable would have finished in the same tick. Same thing with cancellable promises. I'm really fine either way (although I prefer avoiding unexpected behaviours even if per se technically correct) as long it is documented and that we strive towards consistency. |
Honestly, I doubt the TSC is going to make a decision on any of this tomorrow--the conversation will be started, sure, but I wouldn't expect immediate resolution. So given that, lots of scope and context is fine. I'll add a note and a link here to the TSC agenda, but I predict most TSC members won't actually follow along until after the meeting. |
@jasnell I think that I'm +1 in adding a @ronag can you make sure we do not emit |
Yep, I agree that |
Agreed @jasnell |
So should I add some kind of option flag? Any name suggestions? |
If we add |
@Trott: I think this needs a WIP label while we figure out what we want. |
I don't know what to do here... Closing until someone can provide some consensus on what to do. |
When destroying, the stream will be potentially incomplete and therefore it doesn't make sense to emit finish.
Also simplify and inline related conditions.
After
destroy()
(in general) we should really only be emitting'close'
and possibly'error'
.As we do in
fs
the user should callend()
if they want to gracefully close/destroy a stream (#15407).Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesNOTE TO SELF: do minor refactoring and cleanup after merge