-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
Revert "http2: fix end without read" #20832
Conversation
This reverts commit 8d38288.
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 :(
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 should not be reverted. There's a bug in http2 that's just being exacerbated here (well, not truly — it's just showing that this bug exists) but this isn't the root cause.
The test case — as modified here — won't even survive on any version but this one. It has 100% failure prior to this commit.
As for the bug, it's as @BridgeAR stated — same root cause as the already opened issue for all the others. I'm working on a fix but it's complicated, might take another day.
Please consider having a look at #20772 and helping with the effort in there. There are serious bugs in http2 that need to be resolved. Everything works as expected on Linux & macOS now but FreeBSD & Windows assistance is desperately needed. Thanks! |
@apapirovski our process is to typically keep the CI green. Unless it's a very easy fix, we prefer to revert quickly and send a follow-up PR that re-add the functionality. |
cc @nodejs/tsc. |
@mcollina if we really want to keep the CI green — even though there are currently at least two serious bugs in http2 — then we should revert the change to the test only and not the rest of this PR, which has nothing to do with the CI being red. From my perspective this might at least encourage people to look at the bug. We are too quick to revert or label things as flaky to achieve perceived stability. Instead those things just end up buried and never attended to in the future. Just my opinion, of course... |
The goal is not perceived stability, it’s other people’s ability to tell whether the failures they are seeing are coming from their own changes or not.
That seems fine to me too. |
Oh, but generally: We should always be quick to revert if anything broke. I still think we should just land this asap and re-open a PR with the original changes, minus test changes. |
I opened #20835 as alternative. It just skips the flaky tests in case of failures. I think that is currently the best solution until the underlying issue gets fixed. |
This reverts commit 8d38288.
Refs: #20621
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes