Version

Reproduced on v24.18.0 and v26.11.1, with 20/20 failures on each. v26.11.1 was the node npm package's latest version when tested.

Platform

Linux 6.12.95+deb13-amd64, x86_64 GNU/Linux.

The installed v24.18.0 reports nghttp2 1.69.0 and OpenSSL 3.5.7. v26.11.1 was tested using npm exec --yes --package=node@26.11.1 -- node ....

Subsystem

http2, stream (ClientHttp2Stream readable async iteration / end-of-stream handling).

What steps will reproduce the bug?

A standalone, dependency-free reproduction gist:

https://gist.github.com/jbeda/cb47933e03eb33febf937c159b780b9b

Pinned script: https://gist.githubusercontent.com/jbeda/cb47933e03eb33febf937c159b780b9b/raw/6502872f0d06b6c3b93ee1c83ab17b4c19dbe7e2/repro.mjs

Save the gist's repro.mjs locally and run:

node repro.mjs

No package installation, proxy, Go server, or gRPC library is required. It uses node:http2 as the client and a small node:net peer bound to a loopback ephemeral port. The peer writes explicit HTTP/2 frames with a static-table :status: 200 HPACK entry and a literal grpc-status: 0 trailer. The body is synthetic plain bytes, not protobuf or gRPC framing.

The script synchronizes on events, without scheduling sleeps or retries:

1. Client starts a POST, writes some request bytes, and deliberately does not call request.end().
2. Peer sends response HEADERS and initial DATA.
3. Client creates the built-in async iterator, consumes the initial DATA, verifies writableEnded === false, then pauses iteration.
4. Peer sends final DATA, trailers with END_STREAM, and RST_STREAM(NO_ERROR) in that order in one socket write. The reset does not overtake the response bytes on the wire.
5. Client waits for trailers and the reset-induced aborted event. It verifies grpc-status === '0', rstCode === 0, and that all 17 final response bytes remain buffered.
6. Client resumes the existing iterator. It receives and verifies the exact final bytes.
7. The following next() throws ERR_STREAM_PREMATURE_CLOSE instead of returning EOF.

The five-second timeout only catches a hung reproduction. Session/socket destruction is in finally, after the EOF read; it does not cause the failure.

How often does it reproduce? Is there a required condition?

Deterministic with the event-gated sequence above. I tested the failing case and both controls 20 times each on both runtimes, checking the failing exit status, specific error code, and complete-byte receipt:

Controls:

node repro.mjs no-reset
node repro.mjs drained

The relevant conditions are an open request side, an already-created readable async iterator, and response DATA still buffered when a post-response NO_ERROR reset arrives. Without event gating, this manifests intermittently in application traffic.

What is the expected behavior? Why is that the expected behavior?

The request side is closed by the reset, but the complete response remains consumable and the readable iterator finishes normally. Successful response END_STREAM has already arrived and every response byte can still be read.

RFC 9113 section 8.1 explicitly permits RST_STREAM(NO_ERROR) after a complete response while a request remains in progress and says clients must not discard responses because of such a reset. Both control cases demonstrate clean EOF on the same response content.

What do you see instead?

On v24.18.0:

{"node":"v24.18.0","mode":"reset","status":"0","rstCode":0,"readableLength":17,"writableEnded":true}
Complete response bytes received.
node:internal/streams/end-of-stream:166
                             new ERR_STREAM_PREMATURE_CLOSE());
                             ^

Error [ERR_STREAM_PREMATURE_CLOSE]: Premature close
    at ClientHttp2Stream.onclose (node:internal/streams/end-of-stream:166:30)
    at ClientHttp2Stream.emit (node:events:521:24)
    at closeStream (node:internal/http2/core:2033:14)
    at Http2Stream.onStreamClose (node:internal/http2/core:605:5) {
  code: 'ERR_STREAM_PREMATURE_CLOSE'
}

Node.js v24.18.0

writableEnded becomes true upon reset; it was explicitly checked as false before sending completion, and the script never calls request.end().

v26.11.1 also yields all response bytes and then throws, with getEosOnCloseError at end-of-stream:98, onclose at end-of-stream:265, and closeStream at http2/core:2088.

Additional information

Related, but a different reproducer from #65677 / #65689: that issue ends the request and begins iteration after normal stream closure. It lists v24.18.0 as passing. This case leaves the request open and starts/consumes the iterator before closure; it fails on v24.18.0 as well. I have not tested #65689's proposed patch against this case and am not claiming it fixes or fails to fix it.

The observed sequence suggests readable end-of-stream handling interprets the reset-induced duplex aborted event as premature response termination while completed-response bytes are buffered. Those bytes can subsequently be yielded, but the iterator retains a premature-close error for its next read. This is a mechanism hypothesis for maintainers to validate, not a proposed production monkeypatch.

This was observed in the wild with gRPC, but it is a more general HTTP/2 response-consumption issue. The standalone reproduction uses only Node core and synthetic response bytes; it does not depend on gRPC or an application framework.

Filing this to determine whether the open-request/active-iterator case belongs with #65677 or requires separate handling.