-
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
net: ensure net.connect calls Socket connect #12861
Conversation
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, though a couple cosmetic requests.
/cc @tobespc
lib/net.js
Outdated
|
||
let normalized; | ||
// If passed an array, it's treated as an array of arguments that have | ||
// already been normalized (so we don't normalize more than once). This have |
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.
"This has"
lib/net.js
Outdated
// If passed an array, it's treated as an array of arguments that have | ||
// already been normalized (so we don't normalize more than once). This have | ||
// been solved before in https://github.com/nodejs/node/pull/12342, but was | ||
// reverted as it had uninteded side effects. |
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.
"unintended"
@@ -0,0 +1,39 @@ | |||
'use strict'; | |||
|
|||
// This test checks that calling `net.connect` internally calls |
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.
I don't know why it was chosen, but the standard is for the test description to be later in the file.
/cc @bnoordhuis |
LGTM |
@sam-github I think I addressed all your review point 😃 |
const net = require('net'); | ||
const Socket = net.Socket; | ||
|
||
// monkey patch Socket.prototype.connect to check that it's called |
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.
Style is to capitalize sentence and add a period. Sorry for the nitpicking.
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.
@sam-github np 😄 Just amended the commit with a fix 😃
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, though one sentence could be capitalized and punctuated.
You did, thank you. |
// - https://github.com/nodejs/node/pull/12852 | ||
|
||
const net = require('net'); | ||
const Socket = net.Socket; |
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.
Actually, feel free to just go with const { Socket } = require('net');
if you like.
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.
net.connect
is used as well.
It's important for people who monkey-patch `Socket.prototype.connect` that it's called by `net.connect` since it's not possible to monkey-patch `net.connect` directly (as the `connect` function is called directly by other parts of `lib/net.js` instead of calling the `exports.connect` function). Among the actors who monkey-patch `Socket.prototype.connect` are most APM vendors, the async-listener module and the continuation-local-storage module. Related: - nodejs#12342 - nodejs#12852
I'm not sure if it's this PR or something else but I'm seeing the following when using
Might be an unrelated issue? Doesn't happen w/o CLS. I was using latest |
Just tested - EADDRNOTAVAIL doesn't happen with this commit's parent (bc05436). Will do some more digging. |
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.
With this change it's possible to make async-listener
work again, 👍 for shipping it.
@jkrems Ok, so the c-l-s thing you mentioned in #12861 (comment) is not a problem? |
@sam-github Well, it's not like |
@jkrems OK, will you land? Or will @watson? I'm a bit confused, you both have "Member" tags, but only your name is on https://github.com/nodejs/node#collaborators. Generally, the PR author lands if they are a collaborator, so I don't want to land if Thomas can. |
New CI just in case: https://ci.nodejs.org/job/node-test-pull-request/7945/
|
@sam-github I don't have commit bit, so I don't think I can land it personally. @jkrems I opened a tracking issue a few days ago on c-l-s to let people know about this problem: othiym23/node-continuation-local-storage#117 |
Landed in 212a7a6 |
It's important for people who monkey-patch `Socket.prototype.connect` that it's called by `net.connect` since it's not possible to monkey-patch `net.connect` directly (as the `connect` function is called directly by other parts of `lib/net.js` instead of calling the `exports.connect` function). Among the actors who monkey-patch `Socket.prototype.connect` are most APM vendors, the async-listener module and the continuation-local-storage module. Related: - #12342 - #12852 PR-URL: #12861 Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Luca Maraschi <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jan Krems <[email protected]>
It's important for people who monkey-patch `Socket.prototype.connect` that it's called by `net.connect` since it's not possible to monkey-patch `net.connect` directly (as the `connect` function is called directly by other parts of `lib/net.js` instead of calling the `exports.connect` function). Among the actors who monkey-patch `Socket.prototype.connect` are most APM vendors, the async-listener module and the continuation-local-storage module. Related: - nodejs#12342 - nodejs#12852 PR-URL: nodejs#12861 Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Luca Maraschi <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jan Krems <[email protected]>
I'd really love to have this backported to 7.x as well. Is it @MylesBorins or @jasnell that's responsible for backporting? |
It's @nodejs/backporting these days. We're not planning to do another 7.x release unless there's a really good reason to (it's EoL). Is there a reason you specifically wanted it on 7.x? |
@gibfahn Thanks for the reply 😃 I appreciate the situation, but here's my situation (FYI: my frustrations are probably leaking though, so don't take any of it personal 😉): This was discovered before 8 was out, so it was actually my understanding from talking to @MylesBorins that it would be included in a 7.x release, but apparently none was made 😬 My main concern is that a lot of CI's are failing because of this as people still test against 7. And people are probably still running 7 in the wild and are therefore affected by this (though hopefully they will upgrade to 8 over time as it gets more stable). This is a lot of time wasted debugging for a lot of people. The CI builds for Node.js 7 for both async-listener, continuation-local-storage and opbeat all fail because of this which means we're flying blind. And most likely a lot of others, so It's very disrupting (see for instance this comment: othiym23/async-listener#113 (comment)). I of course understand that we don't wanna make updates to a branch that's now EoL, but it's sad to leave 7.x in a state that breaks so much of the community. From a personal perspective getting this into 7 will make my life a lot easier. As I said, it's not my intention to offend anybody or the current process 😅 |
Thanks @watson , that's the reason I was looking for. 7.x releases have mainly been done by @evanlucas and @cjihrig AIUI (but it could be done by anyone in @nodejs/release).
Doesn't come across as offensive, the current process is that we won't release unless there's a good reason, seems like you're providing a good reason so that's helpful. |
I agree that there should be another v7.x release. I just frankly haven't had the time to do so. |
@evanlucas Let me know if there's anything I can do to help or make the process easier 😃 |
I think a final 7.x release makes sense |
#12342 is dont-land, so marking the same for this. LMK if you disagree. |
Will this land in the planned security release for 7.x that's coming out this week? Please, please, please 😅 |
I guess cc/ @mhdawson |
We are not planning to include any commits unrelated to security in the
upcoming release
…On Jul 11, 2017 12:44 PM, "Gibson Fahnestock" ***@***.***> wrote:
Will this land in the planned security release for 7.x that's coming out
this week? Please, please, please
I guess cc/ @mhdawson <https://github.com/mhdawson>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#12861 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAecVwsLraXlWBuPAkEdenOBYPEw-Mn5ks5sM1__gaJpZM4NR_VT>
.
|
@watson See https://github.com/nodejs/LTS/blob/master/doc/meetings/2017-05-15.md#clarify-what-happens-with-odd-numbered-releases-in-april-128 for some notes 7.x has no support, it was debated whether it should ever get any updates, for any reason (including security), after 8.x was available, and I think we settled on "ok, maybe for a really minimal amount of time, but no promises for the future". And no one should have been using 7.x for production, they are just one step more stable than nightly builds (not very stable). Which of course doesn't help you if one of your customers happens to be doing just that :-(. Maybe comment on the LTS issue if you have some thoughts on what to do when we come out with a new major, with some feedback on what your customers are doing and impact on them. |
@sam-github did you see #12861 (comment)? I understod from @evanlucas that this was one of those exceptions? |
@watson I don't claim to perfect understanding, but my reading of what @evanlucas said is that he personally wants to do a 7.x release, and I don't think anyone would object if he wanted to, but I'm not sure the LTS WG is comitted to that. I think its more out of his personal interest. I think opening an issue in the LTS issue tracker to request another 7.x might be the best way of getting a definitive yes/no on a 7.x patch/bug fix release. |
@watson I apologize. My original intention was to include this in the v7.10.1 release, but it slipped my mind during preparation. Sorry |
No worries. I'll open up an issue in the LTS issue tracker 👍 |
This is an alternative PR to #12852 that avoids reverting bb06add.
cc: @cjihrig @addaleax @jasnell
Background
It's important for people who monkey-patch
Socket.prototype.connect
that it's called bynet.connect
since it's not possible to monkey-patchnet.connect
directly (as theconnect
function is called directly by other parts oflib/net.js
instead of calling theexports.connect
function).Among the actors who monkey-patch
Socket.prototype.connect
are most APM vendors, the async-listener module and the continuation-local-storage module.Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
Related