Skip to content
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

stream: finished should invoke callback for closed streams #31509

Closed
wants to merge 2 commits into from

Conversation

ronag
Copy link
Member

@ronag ronag commented Jan 25, 2020

Previously finished(stream, cb) would not invoke the callback for streams
that have already finished, ended or errored before being
passed to finished(stream, cb).

Ref: #31508
Ref: #31314 (comment)

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

@nodejs-github-bot nodejs-github-bot added the lib / src Issues and PRs related to general changes in the lib or src directory. label Jan 25, 2020
@ronag ronag requested a review from mcollina January 25, 2020 16:33
@ronag ronag added semver-major PRs that contain breaking changes and should be released in the next major version. stream Issues and PRs related to the stream subsystem. labels Jan 25, 2020
Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a few tests with autoDestroy: false and autoClose: false? I know these are edge/possibly legacy cases in v14, but it's important we document that behavior as well.

@ronag
Copy link
Member Author

ronag commented Jan 25, 2020

@mcollina: good call, updated

@lpinca
Copy link
Member

lpinca commented Jan 25, 2020

I don't know. In my opinion passing an already "finished" stream to finished() is a usage error so I think it should throw instead of calling the callback.

@mcollina
Copy link
Member

I think throwing would be bad for usability, I would rather call the callback with an error.

I'm ok in both erroring or not erroring as long as something happens.

@ronag
Copy link
Member Author

ronag commented Jan 25, 2020

I’m good with send error into callback as well. @mcollina that would break some existing use cases, such as the one in your revert PR, i.e. Async iterating a destroyed stream.

@ronag
Copy link
Member Author

ronag commented Jan 25, 2020

Though it would make things more difficult. Because we have to distinguish between a closed and a closing stream. Not sure that is possible in a safe way considering compat.

@lpinca
Copy link
Member

lpinca commented Jan 25, 2020

I think throwing is the right thing to do from an API consistency and logical point of view but I'm fine either way. It doesn't make much sense to me to pass an already "finished" stream to finished().

@ronag
Copy link
Member Author

ronag commented Jan 25, 2020

I think throwing is the right thing to do from an API consistency and logical point of view but I'm fine either way. It doesn't make much sense to me to pass an already "finished" stream to finished().

The problem is that it's quite difficult currently for users to determine whether a stream is "finished" and what that exactly means. Though I agree some kind of error would be better but I think it's a bit more complicated and therefore I would prefer to land this PR as is. My understanding is that neither of you are opposed to this?

@mcollina
Copy link
Member

I’m not opposed.

@ronag
Copy link
Member Author

ronag commented Jan 26, 2020

This needs another TSC approval. @jasnell @addaleax?

@nodejs-github-bot
Copy link
Collaborator

@ronag
Copy link
Member Author

ronag commented Jan 26, 2020

Rebased to fix conflict.

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@ronag ronag added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Jan 26, 2020
@Trott
Copy link
Member

Trott commented Jan 27, 2020

I’m not opposed.

@mcollina Does this mean your change request can be cleared?

@Trott
Copy link
Member

Trott commented Jan 27, 2020

Removing author ready until this gets at least one approval.

@Trott Trott removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Jan 27, 2020
Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@ronag
Copy link
Member Author

ronag commented Jan 29, 2020

I would prefer to know what is the fix for spawn-wrap and if it's feasible to support both < 14 and 14.

I can't reproduce the async-wrap issue on MacOS.

I would expect spawn-wrap to fail on multiple platforms if it were affected by this. I think it's OK.

Seems to fail on Debian.

@nodejs-github-bot

This comment has been minimized.

@nodejs-github-bot

This comment has been minimized.

@nodejs-github-bot
Copy link
Collaborator

@ronag
Copy link
Member Author

ronag commented Jan 31, 2020

CI passes

@ronag
Copy link
Member Author

ronag commented Jan 31, 2020

spawn-wrap flaky issue #31596

@ronag
Copy link
Member Author

ronag commented Feb 1, 2020

@Trott: Opinon on CITGM? Can this land?

@Trott
Copy link
Member

Trott commented Feb 5, 2020

@Trott: Opinon on CITGM? Can this land?

CITGM looks OK (but this needs a rebase....)

Previously finished(stream, cb) would not invoke the callback for streams
that have already finished, ended or errored before being
passed to finished(stream, cb).
@ronag
Copy link
Member Author

ronag commented Feb 5, 2020

rebased

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

ronag added a commit that referenced this pull request Feb 8, 2020
Previously finished(stream, cb) would not invoke the callback
for streams that have already finished, ended or errored
before being passed to finished(stream, cb).

PR-URL: #31509
Refs: #31508
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
@ronag
Copy link
Member Author

ronag commented Feb 8, 2020

Landed in d016b9d

@ronag ronag closed this Feb 8, 2020
@lpinca lpinca mentioned this pull request Feb 16, 2020
4 tasks
const onlegacyfinish = () => {
if (!stream.writable) onfinish();
};

let writableFinished = stream.writableFinished ||
(stream._writableState && stream._writableState.finished);
(rState && rState.finished);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like wState should be here instead of rState

@ronag ronag mentioned this pull request Feb 20, 2020
4 tasks
ronag added a commit to nxtedition/node that referenced this pull request Feb 20, 2020
nodejs#31509 introduced a slight typo.
Fortunately this typo does not have big impact due to
`isWritableFinished()`.

Fixes: nodejs#31509 (comment)
ronag added a commit that referenced this pull request Feb 22, 2020
#31509 introduced a slight typo.
Fortunately this typo does not have big impact due to
`isWritableFinished()`.

Fixes: #31509 (comment)

PR-URL: #31881
Fixes: #31509
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. lib / src Issues and PRs related to general changes in the lib or src directory. semver-major PRs that contain breaking changes and should be released in the next major version. stream Issues and PRs related to the stream subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants