Forget closed http2 streams

[davedoesdev]

Fixes: #23116

Checklist

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

[addaleax]

@nodejs/http2

[jasnell]

Lgtm with green ci

[addaleax]

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

[davedoesdev]

I'm afraid I don't understand the test results.
I can see a test timeout for this change, which doesn't occur when I run it locally.

[davedoesdev]

I can make the test run quicker by decreasing maxSessionMemory and thus the number of iterations

[mcollina]

LGTM

[jasnell]

The test likely should go into test/sequential or maybe even test/pummel

[addaleax]

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

@davedoesdev If a tests takes longer than 20s or so, you might want to consider moving it to test/pummel/. But if we can avoid that, that would be ideal, because those tests aren’t run as part of regular CI runs.

[davedoesdev]

The revised test should only take a few seconds.

The new CI test failure on Linux is test.parallel/test-gc-http-client-timeout.
The failure on Windows is test-net-connect-options-port

[danbev]

Re-run of CI: https://ci.nodejs.org/job/node-test-pull-request/17576/

[davedoesdev]

Those tests are failing ontest-gc-net-timeout.

I notice that other PRs (e.g. https://ci.nodejs.org/job/node-test-pull-request/17567/) are also failing.

Are the CI tests usually 100% pass?

[lpinca]

Nit: can't we use stream.resume() instead of piping to a dummy writable?

[lpinca]

Are the CI tests usually 100% pass?

No, there are some flaky tests.

[danbev]

Re-run of failing node-test-commit-linux ✔️
Re-run of failing node-test-commit-smartos ✔️

[danbev]

Landed in e8121d5.