Skip to content

Conversation

@ronag
Copy link
Member

@ronagronag commented Jan 6, 2021

Futher aligns OutgoingMessage with stream.Writable. In particular
re-uses the construct/destroy logic from streams.

Due to a lot of subtle assumptions this PR unfortunately touches
a lot of different parts.

@ronagronag added http Issues or PRs related to the http subsystem. stream Issues and PRs related to the stream subsystem. labels Jan 6, 2021
@mcollinamcollina added the semver-major PRs that contain breaking changes and should be released in the next major version. label Jan 6, 2021
@ronag
Copy link
MemberAuthor

ronag commented Jan 6, 2021

@nodejs/http

@ronag
Copy link
MemberAuthor

ronag commented Jan 6, 2021

I've removed the following tests:

  • test/parallel/test-http-agent-uninitialized-with-handle.js
  • test/parallel/test-http-agent-uninitialized.js

They fail and I'm confused as to what they are supposed to test and how they could work.

@ronagronag requested review from addaleax and lpincaJanuary 6, 2021 19:15
@ronag
Copy link
MemberAuthor

ronag commented Jan 6, 2021

@dnlup

@dnlup
Copy link
Contributor

dnlup commented Jan 7, 2021

I've removed the following tests:

  • test/parallel/test-http-agent-uninitialized-with-handle.js
  • test/parallel/test-http-agent-uninitialized.js

They fail and I'm confused as to what they are supposed to test and how they could work

From 93f47b1#diff-82c531677b9ab4e260025e0397fb0ac4d4316459fa5d16346324e39584cfce96R170 , it looks like they're trying to check that Agent#addRequest does not break if the socket does not have a _handle. The comments say that it could happen if the socket is uninitialized or supplied by the user. I am not sure how this could happen in a use case scenario. What are the errors you were encountering in the tests?

@ronagronagforce-pushed the http-outgoing branch 2 times, most recently from d1a8699 to 60d2417CompareJanuary 7, 2021 08:13
@ronagronag added the wip Issues and PRs that are still a work in progress. label Jan 7, 2021
@ronagronagforce-pushed the http-outgoing branch 2 times, most recently from b7bdc6a to c18b3b4CompareJanuary 7, 2021 08:20
@ronagronagforce-pushed the http-outgoing branch 4 times, most recently from ba8188e to 09f6982CompareJanuary 7, 2021 11:04
@ronag
Copy link
MemberAuthor

ronag commented Jan 7, 2021

From 93f47b1#diff-82c531677b9ab4e260025e0397fb0ac4d4316459fa5d16346324e39584cfce96R170 , it looks like they're trying to check that Agent#addRequest does not break if the socket does not have a _handle. The comments say that it could happen if the socket is uninitialized or supplied by the user. I am not sure how this could happen in a use case scenario. What are the errors you were encountering in the tests?

Would you like to have a go at trying to make those test pass?

@ronagronag added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Jan 31, 2021
@ronag
Copy link
MemberAuthor

ronag commented Feb 5, 2021

@nodejs/http any chance to get some review on this PR?

@benjamingr
Copy link
Member

It looks like this needs TSC approvals to land and the TSC ping didn't help - pinging @nodejs/tsc

@benjamingrbenjamingr added the tsc-agenda Issues and PRs to discuss during the meetings of the TSC. label Feb 9, 2021
@Trott
Copy link
Member

This looks good to me and I'll approve it if it ends up one TSC approval short of landing or something like that. But for things that are at the intersection of http and streams, I tend to wait for @mcollina and/or @lpinca to review first.

@apapirovski
Copy link
Contributor

apapirovski commented Feb 25, 2021

My biggest concern here is that this is a pretty "soft" alignment. It's done through explicitly modifying the logic and flows to mirror stream.Writable. That is fine but it does introduce additional future maintenance burden and more opportunity for weird, unexpected divergence that is less of an issue the way things are setup right now. To be clear, this is not a criticism of the approach — I understand why it's done the way it is, it's more pointing out that this does create shared behavior through code duplication.

At the very least, I think some new tests should be introduced that document expected behavior and assumptions that can be made about http.OutgoingMessage that is more closely aligned with stream.Writable. In particular I think we need tests that document the introduction of _writableState and Writable.prototype in a variety of places. That's just my 2c but I'm also more risk-averse than most when it comes to the http module.

@ronag
Copy link
MemberAuthor

ronag commented Feb 25, 2021

That is fine but it does introduce additional future maintenance burden and more opportunity for weird, unexpected divergence that is less of an issue the way things are setup right now.

I'm not sure I follow this line of thought? IMHO These changes should make it easier to maintain this and all stream related helpers and interop?

@apapirovski
Copy link
Contributor

apapirovski commented Feb 25, 2021

IMHO There changes should make it easier to maintain this and all stream related helpers and interop?

The closer you get while still having custom logic & duplicate code, the harder it is to not accidentally diverge in some minute way. At least without having equivalent test suites for both.

FWIW don't take this as me saying this is a bad change. I think it's great we're moving in this direction, although I would prefer to better align test coverage with Writable.

@ronag
Copy link
MemberAuthor

FWIW my intention here is to eventually implement it fully in terms of Writable (or some form of WritableBase).

@jasnell
Copy link
Member

Sorry for not looking at this sooner. The changes themselves look fine to me but I'd like @mcollina to weigh in before signing off.

Copy link
Member

@mcollinamcollina 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 caution. We might end up to revert this if it will lead to massive ecosystem breakage.

@nodejs-github-bot
Copy link
Collaborator

@ronag
Copy link
MemberAuthor

ronag commented Mar 8, 2021

Should we label this as a notable change?

@mcollinamcollina added the notable-change PRs with changes that should be highlighted in changelogs. label Mar 8, 2021
@mcollina
Copy link
Member

Yes indeed

Futher aligns OutgoingMessage with stream.Writable. In particular re-uses the construct/destroy logic from streams. Due to a lot of subtle assumptions this PR unfortunately touches a lot of different parts.
@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@ronag
Copy link
MemberAuthor

Landed in e2f5bb7

@ronagronag closed this Mar 10, 2021
ronag added a commit that referenced this pull request Mar 10, 2021
Futher aligns OutgoingMessage with stream.Writable. In particular re-uses the construct/destroy logic from streams. Due to a lot of subtle assumptions this PR unfortunately touches a lot of different parts. PR-URL: #36816 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

author readyPRs that have at least one approval, no pending requests for changes, and a CI started.httpIssues or PRs related to the http subsystem.notable-changePRs with changes that should be highlighted in changelogs.review wantedPRs that need reviews.semver-majorPRs that contain breaking changes and should be released in the next major version.streamIssues and PRs related to the stream subsystem.tsc-agendaIssues and PRs to discuss during the meetings of the TSC.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants

@ronag@dnlup@nodejs-github-bot@mcollina@cjihrig@Trott@benjamingr@apapirovski@jasnell