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: remove TODO and add a description instead #27086

Closed
wants to merge 2 commits into from

Conversation

BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Apr 4, 2019

After looking into this it turned out that these two errors are
sanity checks that should not be reached. It is unfortunate that
we assigned error codes for these but changing it into an assertion
seems to be a hassle for readable-streams.

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

After looking into this it turned out that these two errors are
sanity checks that should not be reached. It is unfortunate that
we assigned error codes for these but changing it into an assertion
seems to be a hassle for `readable-streams`.
@nodejs-github-bot nodejs-github-bot added the stream Issues and PRs related to the stream subsystem. label Apr 4, 2019
@nodejs-github-bot
Copy link
Collaborator

@BridgeAR BridgeAR requested a review from mcollina April 4, 2019 19:03
@BridgeAR BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Apr 4, 2019
// TODO(BridgeAR): Write a test for these two error cases
// if there's nothing in the write buffer, then that means
// that nothing more will ever be provided
// These two error cases are sanity checks that can likely not be tested.
Copy link
Member

@Trott Trott Apr 5, 2019

Choose a reason for hiding this comment

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

Does this mean that the errors should be impossible in theory? Or simply difficult to test? If impossible, let's change them to assert() instead?

Copy link
Member

Choose a reason for hiding this comment

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

We should not depend on assert() in readable-stream (bundle size, etc), and I would need to spend time to actually remove it with regexps. So, can we avoid adding it in the first place?

Copy link
Member

Choose a reason for hiding this comment

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

We should not depend on assert() in readable-stream (bundle size, etc), and I would need to spend time to actually remove it with regexps. So, can we avoid adding it in the first place?

Yeah, I wasn't meaning lib/assert.js but rather the tiny (15 LoC) lib/internal/assert.js (that conditionally loads lib/assert.js only if it is actually throwing). But I guess that doesn't help readable-stream?

Copy link
Member

Choose a reason for hiding this comment

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

not at all :/.

Copy link
Member

Choose a reason for hiding this comment

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

OK, in that case, how about just clearing up the comment to indicate whether this is something that is believed to logically be impossible (that is: we believe this error should never happen) or if it's just something that will indeed happen from time to time (due to bugs in people's code or problems on a host or whatever) and is merely difficult/impossible to reliably test.

Copy link
Member Author

Choose a reason for hiding this comment

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

(internal/assert has nothing to do with assert anymore. They are 100% independent)

Copy link
Member

Choose a reason for hiding this comment

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

I highly prefer not to, because it will make it harder to track future changes to that file as well. Adding another require could lead to 1-3 days of added work, and I prefer to be conservative for what is currently ok.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok, I struggle what to do here in this case. @Trott are you fine with this comment due to the issues with readable-streams?

Copy link
Member

Choose a reason for hiding this comment

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

Ok, I struggle what to do here in this case. @Trott are you fine with this comment due to the issues with readable-streams?

Yeah, consider my comments to be nits. Would love to have consensus on something that makes everyone happy and addresses my comments/questions, but ultimately, I'm fine with whatever you and Matteo can agree on.

Copy link
Member Author

Choose a reason for hiding this comment

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

Another alternative would be to remove these checks completely.
@mcollina are you fine with that?

lib/_stream_transform.js Outdated Show resolved Hide resolved
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 with the given wording, thanks.

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@BridgeAR
Copy link
Member Author

BridgeAR commented May 2, 2019

Landed in 57fd70f 🎉

@BridgeAR BridgeAR closed this May 2, 2019
BridgeAR added a commit to BridgeAR/node that referenced this pull request May 2, 2019
After looking into this it turned out that these two errors are
sanity checks that should not be reached. It is unfortunate that
we assigned error codes for these but changing it into an assertion
seems to be a hassle for `readable-streams`.

PR-URL: nodejs#27086
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
targos pushed a commit that referenced this pull request May 4, 2019
After looking into this it turned out that these two errors are
sanity checks that should not be reached. It is unfortunate that
we assigned error codes for these but changing it into an assertion
seems to be a hassle for `readable-streams`.

PR-URL: #27086
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
@targos targos mentioned this pull request May 6, 2019
@BridgeAR BridgeAR deleted the change-comment branch January 20, 2020 12:03
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. stream Issues and PRs related to the stream subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants