[v8.x] https: revert "refactor to use http internals" #16660
Conversation
|
Is there a bug report of some kind somewhere? Also, our release tooling is designed to handle git’s built-in |
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: nodejs#16395
MylesBorins
force-pushed
the
revert-16395
branch
from
9281bc1
to
230352c
Compare
|
@addaleax There are two comments found at #16395 (comment) lmk if commit message looks good |
MylesBorins
changed the title
I'm assuming you meant 9? |
|
@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 |
|
P.S. any good candidate for CitGM in the failures? |
|
No reason to revert, IMO. We don't promise that internals won't change. People monkey-patching core APIs know and accept that. |
|
@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 |
|
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. |
|
Kinda -1 on reverting this for the same reasons @bnoordhuis is. Also, I don't think semver-major really applies to internal implementation details. |
|
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. |
|
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. |
|
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 |
|
I'm fine with reverting in 8.x only |
|
@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? |
|
@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. |
|
@MylesBorins ack on semver level. |
|
@refack I don't believe that we should make a formal policy around reverts aside from revert often and quickly. |
|
Also for clarity, with the added information from this thread I see no reason for this change to be treated as |
|
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. |
There was a problem hiding this comment.
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
|
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. |
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 |
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 |
@MylesBorins why? |
Not necessarily. In our case we were explicitly not instrumenting the |
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 <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Bryan English <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Jan Krems <[email protected]>
|
landed in 08b75c1 |
|
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 |
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
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