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

[v8.x] https: revert "refactor to use http internals" #16660

Closed
wants to merge 1 commit into
base: v8.x-staging
from

Conversation

@MylesBorins
Member

MylesBorins commented Nov 1, 2017

This reverts commit 5118f31 on the v8.x release line

It is breaking code in the wild that depends on the original behavior
to do tracing.

I don't think we need to necessarily fix this in 9.x but we might want
to reclassify the original commit as Semver Major

Refs: #16395

/cc @nodejs/lts @bengl @gibfahn @ofrobots

@MylesBorins

This comment has been minimized.

Show comment
Hide comment
Member

MylesBorins commented Nov 1, 2017

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Nov 1, 2017

Member

Is there a bug report of some kind somewhere?

Also, our release tooling is designed to handle git’s built-in revert commit messages and explicitly calls out the commits as reverts if it is used.

Member

addaleax commented Nov 1, 2017

Is there a bug report of some kind somewhere?

Also, our release tooling is designed to handle git’s built-in revert commit messages and explicitly calls out the commits as reverts if it is used.

Revert "https: refactor to use http internals"
This reverts commit 5118f31.

It is breaking code in the wild that depends on the original behavior
to do tracing.

I don't think we need to necessarily fix this in 8.x but we might want
to reclassify the original commit as Semver Major

Refs: #16395
@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins Nov 1, 2017

Member

@addaleax There are two comments found at #16395 (comment)

lmk if commit message looks good

Member

MylesBorins commented Nov 1, 2017

@addaleax There are two comments found at #16395 (comment)

lmk if commit message looks good

@refack

refack approved these changes Nov 1, 2017

@addaleax

Yup, seems good for v8.x!

@MylesBorins MylesBorins changed the title from https: revert "refactor to use http internals" to [v8.x] https: revert "refactor to use http internals" Nov 1, 2017

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Nov 1, 2017

Member

I don't think we need to necessarily fix this in 8.x but we might want
to reclassify the original commit as Semver Major

I'm assuming you meant 9?

Member

refack commented Nov 1, 2017

I don't think we need to necessarily fix this in 8.x but we might want
to reclassify the original commit as Semver Major

I'm assuming you meant 9?

@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins Nov 1, 2017

Member

@refack yeah, I just updated that in the commit message 😅

Waiting for CI to run before pushing because I don't want to restart it again

Member

MylesBorins commented Nov 1, 2017

@refack yeah, I just updated that in the commit message 😅

Waiting for CI to run before pushing because I don't want to restart it again

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Nov 1, 2017

Member

P.S. any good candidate for CitGM in the failures?

Member

refack commented Nov 1, 2017

P.S. any good candidate for CitGM in the failures?

@MylesBorins MylesBorins referenced this pull request Nov 1, 2017

Closed

https: refactor to use http internals #16395

2 of 2 tasks complete
@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins Nov 1, 2017

Member

@addaleax @bengl are you cool with the original commit being relabeled semver major? I'll update changelogs

Member

MylesBorins commented Nov 1, 2017

@addaleax @bengl are you cool with the original commit being relabeled semver major? I'll update changelogs

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Nov 1, 2017

Member

No reason to revert, IMO. We don't promise that internals won't change. People monkey-patching core APIs know and accept that.

Member

bnoordhuis commented Nov 1, 2017

No reason to revert, IMO. We don't promise that internals won't change. People monkey-patching core APIs know and accept that.

@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins Nov 1, 2017

Member

@bnoordhuis does it make sense to knowlingly break people in a patch for such a small optimization? Seems reasonable to give people some time to catch up

Member

MylesBorins commented Nov 1, 2017

@bnoordhuis does it make sense to knowlingly break people in a patch for such a small optimization? Seems reasonable to give people some time to catch up

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Nov 1, 2017

Member

They'll need to update anyway, that's the responsibility you take on when you start monkey-patching core.

There's also the principle of the matter. A hard-line stance avoids future debate.

Member

bnoordhuis commented Nov 1, 2017

They'll need to update anyway, that's the responsibility you take on when you start monkey-patching core.

There's also the principle of the matter. A hard-line stance avoids future debate.

@apapirovski

This comment has been minimized.

Show comment
Hide comment
@apapirovski

apapirovski Nov 1, 2017

Member

Kinda -1 on reverting this for the same reasons @bnoordhuis is. Also, I don't think semver-major really applies to internal implementation details.

Member

apapirovski commented Nov 1, 2017

Kinda -1 on reverting this for the same reasons @bnoordhuis is. Also, I don't think semver-major really applies to internal implementation details.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Nov 1, 2017

Member

Our documented guidelines specifically call out the fact that we can change internals in ways that potentially break. So, yes, in this case semver-major would not apply technically. We have used in the the past, however, out of an abundance of caution to try to avoid breakage but I definitely have to say that I have sympathy for @bnoordhuis' position.

Member

jasnell commented Nov 1, 2017

Our documented guidelines specifically call out the fact that we can change internals in ways that potentially break. So, yes, in this case semver-major would not apply technically. We have used in the the past, however, out of an abundance of caution to try to avoid breakage but I definitely have to say that I have sympathy for @bnoordhuis' position.

@evanlucas

This comment has been minimized.

Show comment
Hide comment
@evanlucas

evanlucas Nov 1, 2017

Member

While I understand the sentiment, I disagree that we shouldn't land this. It doesn't really cost us anything and will keep us from having people that cannot update to use the LTS version of node 8 now. Just my 2 cents though.

Member

evanlucas commented Nov 1, 2017

While I understand the sentiment, I disagree that we shouldn't land this. It doesn't really cost us anything and will keep us from having people that cannot update to use the LTS version of node 8 now. Just my 2 cents though.

@ofrobots

This comment has been minimized.

Show comment
Hide comment
@ofrobots

ofrobots Nov 1, 2017

Contributor

Normally we get feedback for a change on Current for a duration before potentially breaking changes land in LTS. That didn't happen here, which means that there was no warning that this was coming down the pipe before it broke folks that are building diagnostic tooling.

On the flip side, I don't think there is a great argument that this change should go into LTS to begin with. The code review already identified that this is potentially breaking. Restricting this to 9.x+ seems appropriate to me.

Contributor

ofrobots commented Nov 1, 2017

Normally we get feedback for a change on Current for a duration before potentially breaking changes land in LTS. That didn't happen here, which means that there was no warning that this was coming down the pipe before it broke folks that are building diagnostic tooling.

On the flip side, I don't think there is a great argument that this change should go into LTS to begin with. The code review already identified that this is potentially breaking. Restricting this to 9.x+ seems appropriate to me.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Nov 1, 2017

Member

I'm fine with reverting in 8.x only

Member

jasnell commented Nov 1, 2017

I'm fine with reverting in 8.x only

@cjihrig

cjihrig approved these changes Nov 1, 2017

In most cases I strongly agree with core being able to change its own internals. In this case, I'm OK with reverting because this change was identified as possibly breaking and went straight into an LTS release with no baking period in Current.

@ofrobots

This comment has been minimized.

Show comment
Hide comment
@ofrobots

ofrobots Nov 1, 2017

Contributor

@bnoordhuis @apapirovski This revert isn't about preventing core from being able to change internals. It is rather about not putting these changes directly into LTS without a baking period. Reverting it now helps avoid people running into breakages across the ecosystem. Does that formulation help remove your -1?

Contributor

ofrobots commented Nov 1, 2017

@bnoordhuis @apapirovski This revert isn't about preventing core from being able to change internals. It is rather about not putting these changes directly into LTS without a baking period. Reverting it now helps avoid people running into breakages across the ecosystem. Does that formulation help remove your -1?

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Nov 1, 2017

Member

@ofrobots I get your point but it doesn't change mine. I won't rehash my arguments and I won't fight it to death but I feel it sets a bad precedent.

As to the argument that a revert doesn't really cost anything: it makes back-porting fixes from the master branch harder. It's not free.

Member

bnoordhuis commented Nov 1, 2017

@ofrobots I get your point but it doesn't change mine. I won't rehash my arguments and I won't fight it to death but I feel it sets a bad precedent.

As to the argument that a revert doesn't really cost anything: it makes back-porting fixes from the master branch harder. It's not free.

@joyeecheung

This comment has been minimized.

Show comment
Hide comment
@joyeecheung

joyeecheung Nov 1, 2017

Member

Before we revert this, just want to know:

  • (roughly) how many/what packages/application were broken by this change?
  • Are they committed to find a fix for the new behavior?

We should make sure users are willing to fix on their side before reverting, otherwise reverting it in v8.x does not really solve the problem and it does set a bad precedent.

Member

joyeecheung commented Nov 1, 2017

Before we revert this, just want to know:

  • (roughly) how many/what packages/application were broken by this change?
  • Are they committed to find a fix for the new behavior?

We should make sure users are willing to fix on their side before reverting, otherwise reverting it in v8.x does not really solve the problem and it does set a bad precedent.

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Nov 1, 2017

Member

@MylesBorins ack on semver level.
The list of precedents makes a good case for formalizing this ad-hoc policy.
IMHO once we have a formal policy it's easier to draw the line in the sand on principal.

Member

refack commented Nov 1, 2017

@MylesBorins ack on semver level.
The list of precedents makes a good case for formalizing this ad-hoc policy.
IMHO once we have a formal policy it's easier to draw the line in the sand on principal.

@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins Nov 1, 2017

Member

@refack I don't believe that we should make a formal policy around reverts aside from revert often and quickly.

Member

MylesBorins commented Nov 1, 2017

@refack I don't believe that we should make a formal policy around reverts aside from revert often and quickly.

@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins Nov 1, 2017

Member

Also for clarity, with the added information from this thread I see no reason for this change to be treated as Semver-Major. Semver-Patch makes the most sense

Member

MylesBorins commented Nov 1, 2017

Also for clarity, with the added information from this thread I see no reason for this change to be treated as Semver-Major. Semver-Patch makes the most sense

@bengl

This comment has been minimized.

Show comment
Hide comment
@bengl

bengl Nov 1, 2017

Member

I'm -1 on calling this a semver-major, but +1 on the revert. I think the revert will probably help enough folks that it's worth it, but I certainly don't want to set a precedent that internal API changes are semver-major if they only break folks who are doing things with API internals.

Again: +1 on revert, simply for let's-unbreak-people purposes.

Member

bengl commented Nov 1, 2017

I'm -1 on calling this a semver-major, but +1 on the revert. I think the revert will probably help enough folks that it's worth it, but I certainly don't want to set a precedent that internal API changes are semver-major if they only break folks who are doing things with API internals.

Again: +1 on revert, simply for let's-unbreak-people purposes.

@bengl

bengl approved these changes Nov 1, 2017

@joyeecheung

Making it explicit: I am +1 on reverting in v8.x if users are willing to fix other their side, but we should have a better channel to coordinate these changes, before async_hooks are leaves experimental stage there will still be apm vendors sensitive to the internal changes. cc @nodejs/diagnostics

@gireeshpunathil

This comment has been minimized.

Show comment
Hide comment
@gireeshpunathil

gireeshpunathil Nov 2, 2017

Member

I like the idea of: when arguments saturate, favor ecosystem and existing deployments.

monkey-patching seems to originate partly from the language semantics, and partly from the need for monitoring as an essential embodiment of modern workloads. I propose to address monitoring capability in the core as an important focus area.

Member

gireeshpunathil commented Nov 2, 2017

I like the idea of: when arguments saturate, favor ecosystem and existing deployments.

monkey-patching seems to originate partly from the language semantics, and partly from the need for monitoring as an essential embodiment of modern workloads. I propose to address monitoring capability in the core as an important focus area.

@jkrems

jkrems approved these changes Nov 2, 2017

Afaik this change breaks the only reliable way to instrument outgoing HTTP request, so +1 on reverting and I'd actually say we shouldn't have this change anywhere w/o an official API to achieve the same thing.

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Nov 2, 2017

Member

Afaik this change breaks the only reliable way to instrument outgoing HTTP request

It doesn't, you just need to update your code if you were monkey-patching that method.

Matter of fact, if this change broke your tracer it wasn't catching everything in the first place - requests made directly through the ClientRequest interface.

Member

bnoordhuis commented Nov 2, 2017

Afaik this change breaks the only reliable way to instrument outgoing HTTP request

It doesn't, you just need to update your code if you were monkey-patching that method.

Matter of fact, if this change broke your tracer it wasn't catching everything in the first place - requests made directly through the ClientRequest interface.

@jkrems

This comment has been minimized.

Show comment
Hide comment
@jkrems

jkrems Nov 2, 2017

Contributor

Matter of fact, if this change broke your tracer it wasn't catching everything in the first place - requests made directly through the ClientRequest interface.

Okay, maybe I should've said "most reliable way in practice I'm aware of". There's little if any code I ever ran across that was using the ClientRequest constructor directly. Anyhow, the point here is: Landing this directly in an LTS release isn't a great precedent. Thus my 👍 for a revert.

Contributor

jkrems commented Nov 2, 2017

Matter of fact, if this change broke your tracer it wasn't catching everything in the first place - requests made directly through the ClientRequest interface.

Okay, maybe I should've said "most reliable way in practice I'm aware of". There's little if any code I ever ran across that was using the ClientRequest constructor directly. Anyhow, the point here is: Landing this directly in an LTS release isn't a great precedent. Thus my 👍 for a revert.

@gibfahn

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn Nov 2, 2017

Member

@refack I don't believe that we should make a formal policy around reverts aside from revert often and quickly.

@MylesBorins why?

Member

gibfahn commented Nov 2, 2017

@refack I don't believe that we should make a formal policy around reverts aside from revert often and quickly.

@MylesBorins why?

@NatalieWolfe

This comment has been minimized.

Show comment
Hide comment
@NatalieWolfe

NatalieWolfe Nov 2, 2017

Matter of fact, if this change broke your tracer it wasn't catching everything in the first place - requests made directly through the ClientRequest interface.

Not necessarily. In our case we were explicitly not instrumenting the https module because the http instrumentation caught everything. The solution was very simple though, and it matters not to us if this is reverted. Heck, it's less work for me if it isn't. :)

NatalieWolfe commented Nov 2, 2017

Matter of fact, if this change broke your tracer it wasn't catching everything in the first place - requests made directly through the ClientRequest interface.

Not necessarily. In our case we were explicitly not instrumenting the https module because the http instrumentation caught everything. The solution was very simple though, and it matters not to us if this is reverted. Heck, it's less work for me if it isn't. :)

MylesBorins added a commit that referenced this pull request Nov 3, 2017

Revert "https: refactor to use http internals"
This reverts commit 5118f31.

It is breaking code in the wild that depends on the original behavior
to do tracing.

I don't think we need to necessarily fix this in 8.x but we might want
to reclassify the original commit as Semver Major

PR-URL: #16660
Refs: #16395
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Bryan English <bryan@bryanenglish.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Jan Krems <jan.krems@gmail.com>
@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins Nov 3, 2017

Member

landed in 08b75c1

Member

MylesBorins commented Nov 3, 2017

landed in 08b75c1

@MylesBorins MylesBorins closed this Nov 3, 2017

@gibfahn gibfahn referenced this pull request Nov 5, 2017

Merged

v8.9.1 proposal #16783

gibfahn added a commit that referenced this pull request Nov 7, 2017

2017-11-07 Version 8.9.1 'Carbon' (LTS)
- **openssl**:
  - upgrade openssl sources to 1.0.2m (Shigeki Ohtsu) [#16691](#16691)
- ***Revert*** "**https**:
  - refactor to use http internals" (Myles Borins) [#16660](#16660)

PR-URL: #16783

gibfahn added a commit that referenced this pull request Nov 7, 2017

2017-11-07 Version 8.9.1 'Carbon' (LTS)
- **openssl**:
  - upgrade openssl sources to 1.0.2m (Shigeki Ohtsu) [#16691](#16691)
- ***Revert*** "**https**:
  - refactor to use http internals" (Myles Borins) [#16660](#16660)

PR-URL: #16783

gibfahn added a commit that referenced this pull request Nov 7, 2017

2017-11-07, Version 8.9.1 'Carbon' (LTS)
Notable Changes:

- **openssl**:
  - upgrade openssl sources to 1.0.2m (Shigeki Ohtsu) [#16691](#16691)
- ***Revert*** "**https**:
  - refactor to use http internals" (Myles Borins) [#16660](#16660)

PR-URL: #16783

gibfahn added a commit that referenced this pull request Nov 7, 2017

2017-11-07, Version 8.9.1 'Carbon' (LTS)
Notable Changes:

- **openssl**:
  - upgrade openssl sources to 1.0.2m (Shigeki Ohtsu) [#16691](#16691)
- ***Revert*** "**https**:
  - refactor to use http internals" (Myles Borins) [#16660](#16660)

PR-URL: #16783

@MylesBorins MylesBorins deleted the MylesBorins:revert-16395 branch Nov 14, 2017

@danielkhan

This comment has been minimized.

Show comment
Hide comment
@danielkhan

danielkhan Nov 15, 2017

Sorry for being late to the party. I like @MylesBorins pragmatic suggestion to add tooling that removes the need to monkey patch core. I also agree with @NatalieWolfe that async hooks should and could solve that going forward. We should take that as an use case for improvement in nodejs/diagnostics#117

danielkhan commented Nov 15, 2017

Sorry for being late to the party. I like @MylesBorins pragmatic suggestion to add tooling that removes the need to monkey patch core. I also agree with @NatalieWolfe that async hooks should and could solve that going forward. We should take that as an use case for improvement in nodejs/diagnostics#117

mattcolegate added a commit to RuntimeTools/appmetrics that referenced this pull request Jan 15, 2018

Fix https probe after 8.9.1 revert
As the previous change was reverted, and won't go into the 8.x release
line, we only need to do this for 9.0.0 and up.

Refs: nodejs/node#16660

msoechting added a commit to hpicgs/node that referenced this pull request Feb 7, 2018

2017-11-07, Version 8.9.1 'Carbon' (LTS)
Notable Changes:

- **openssl**:
  - upgrade openssl sources to 1.0.2m (Shigeki Ohtsu) [nodejs#16691](nodejs#16691)
- ***Revert*** "**https**:
  - refactor to use http internals" (Myles Borins) [nodejs#16660](nodejs#16660)

PR-URL: nodejs#16783
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment