stream: fix flaky stream destroy, reachable from HTTP/2 teardown

[pimterry]

Some of the HTTP/2 tests have become flaky, e.g. nodejs/reliability#1623 shows yesterday:

• parallel/test-worker-terminate-http2-respond-with-file failed 11 times
• parallel/test-stream-pipeline-http2 failed 10 times

Best guess is these are both due to the window update PR #64623 (cc @mcollina) since the timing lines up exactly. I think this is really just the window size highlighting existing issues though.

This PR fixes the first issue, which triggers flakes in parallel/test-worker-terminate-http2-respond-with-file. I'll kick off a stress test to confirm, but I can reproduce this locally, and reproduced as resolved with this fix. I'm still working on the 2nd, which only reproduces on Mac and seems a bit more complex.

Actual failure in the 1st test is a crash with pure virtual method called. That fires due to ReadStop within this trace:

Worker::Run → FreeEnvironment
  → Environment::RunCleanup
    → BaseObjectList::Cleanup
      → fs::FileHandle::~FileHandle
        → StreamResource::~StreamResource
          → StreamPipe::ReadableListener::OnStreamDestroy
            → StreamPipe::ReadableListener::OnStreamRead

I.e. during destroy within the destructor chain, we call OnStreamRead, which tries to call stream()->ReadStop inside the sources destructor.

This is only called because OnStreamDestroy manually calls OnStreamRead with an error code to reuse its error/eof teardown logic. We don't need most of that in the destruction scenario (which is only ever called from ~StreamResource, where the stream is already dead).

I've refactored out the relevant bit to split them up (just guarding just fails in the next line, where previous_listener_ is also null). That then exposed two other bugs for the same state, where two other methods that get reached later in this teardown flow also fail to check if the stream is already destroyed - those just need simple guards.

Seems like this is a flaky race because it depends on whether the sink (Http2Stream) or the file handle gets destroyed first by Cleanup().

[pimterry]

cc @nodejs/http2

[codecov]

Codecov Report

❌ Patch coverage is 0% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.31%. Comparing base (b33cc0e) to head (2f4238d).
⚠️ Report is 32 commits behind head on main.

Files with missing lines	Patch %	Lines
src/stream_pipe.cc	0.00%	5 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #65079      +/-   ##
==========================================
+ Coverage   90.29%   90.31%   +0.01%     
==========================================
  Files         759      759              
  Lines      247598   247756     +158     
  Branches    46680    46720      +40     
==========================================
+ Hits       223566   223749     +183     
+ Misses      15503    15478      -25     
  Partials     8529     8529              

Files with missing lines	Coverage Δ
src/stream_pipe.cc	58.71% <0.00%> (-1.47%)	⬇️

... and 53 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pimterry]

I'll kick off a stress test to confirm

Stress testing inconclusive - the tests passed on both main and this branch, even with multiple runs. They're definitely failing in PRs though. I can reliably reproduce the reported failure locally (that first failure above, it hits for 2-3% of runs) and validate that it's fixed with this change. The trace is where is crashes on my machine with the matching error, and it's clearly a broken flow, so I think this is the right fix regardless.

[mcollina]

lgtm

I concur with the analysis