Revert "http2: fix end without read"

[BridgeAR]

This reverts commit 8d38288.

Refs: #20621

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[addaleax]

LGTM :(

[BridgeAR]

CI https://ci.nodejs.org/job/node-test-pull-request/14969/

[apapirovski]

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.

[apapirovski]

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!

[mcollina]

@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.

[mcollina]

cc @nodejs/tsc.

[apapirovski]

@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...

[addaleax]

We are too quick to revert or label things as flaky to achieve perceived stability.

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.

then we should revert the change to the test only and not the rest of this PR

That seems fine to me too.

[addaleax]

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.

[BridgeAR]

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.