Skip to content

stream: finished should invoke callback for closed streams#31509

Closed
ronag wants to merge 2 commits into
nodejs:masterfrom
nxtedition:eos-closed
Closed

stream: finished should invoke callback for closed streams#31509
ronag wants to merge 2 commits into
nodejs:masterfrom
nxtedition:eos-closed

Conversation

@ronag

@ronag ronag commented Jan 25, 2020

Copy link
Copy Markdown
Member

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
@ronag ronag requested review from lpinca and mafintosh January 25, 2020 16:37

@mcollina mcollina left a comment

Copy link
Copy Markdown
Member

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

ronag commented Jan 25, 2020

Copy link
Copy Markdown
Member Author

@mcollina: good call, updated

@lpinca

lpinca commented Jan 25, 2020

Copy link
Copy Markdown
Member

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
Copy Markdown
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

ronag commented Jan 25, 2020

Copy link
Copy Markdown
Member Author

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

ronag commented Jan 25, 2020

Copy link
Copy Markdown
Member Author

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

lpinca commented Jan 25, 2020

Copy link
Copy Markdown
Member

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

ronag commented Jan 25, 2020

Copy link
Copy Markdown
Member Author

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
Copy Markdown
Member

I’m not opposed.

@ronag

ronag commented Jan 26, 2020

Copy link
Copy Markdown
Member Author

This needs another TSC approval. @jasnell @addaleax?

@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

@ronag

ronag commented Jan 26, 2020

Copy link
Copy Markdown
Member Author

Rebased to fix conflict.

@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

@nodejs-github-bot

Copy link
Copy Markdown
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

Trott commented Jan 27, 2020

Copy link
Copy Markdown
Member

I’m not opposed.

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

@Trott

Trott commented Jan 27, 2020

Copy link
Copy Markdown
Member

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

@mcollina mcollina left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

lgtm

@ronag

ronag commented Jan 29, 2020

Copy link
Copy Markdown
Member Author

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
Copy Markdown
Collaborator

@ronag

ronag commented Jan 31, 2020

Copy link
Copy Markdown
Member Author

CI passes

@ronag

ronag commented Jan 31, 2020

Copy link
Copy Markdown
Member Author

spawn-wrap flaky issue #31596

@ronag

ronag commented Feb 1, 2020

Copy link
Copy Markdown
Member Author

@Trott: Opinon on CITGM? Can this land?

@Trott

Trott commented Feb 5, 2020

Copy link
Copy Markdown
Member

@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

ronag commented Feb 5, 2020

Copy link
Copy Markdown
Member Author

rebased

@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

@nodejs-github-bot

Copy link
Copy Markdown
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 <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
@ronag

ronag commented Feb 8, 2020

Copy link
Copy Markdown
Member Author

Landed in d016b9d

@ronag ronag closed this Feb 8, 2020
@lpinca lpinca mentioned this pull request Feb 16, 2020
4 tasks

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

Copy link
Copy Markdown

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 <matteo.collina@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
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