Bug

The HTTP/2 client's onResponse handler in lib/dispatcher/client-h2.js calls request.onResponseStart(...) after guarding only request.aborted — but not request.completed:

function onResponse (headers) {
  ...
  if (request.aborted) {            // ← missing `|| request.completed`
    releaseRequestStream(stream)
    return
  }
  if (request.onResponseStart(Number(statusCode), headers, stream.resume.bind(stream), '') === false) {
    stream.pause()
  }
  ...
}

Request.onResponseStart asserts both invariants:

onResponseStart (statusCode, headers, resume, statusText) {
  assert(!this.aborted)
  assert(!this.completed)
  ...
}

So if a 'response' event is delivered to the stream after the request has already completed, onResponse invokes onResponseStart post-completion and trips assert(!this.completed). Because the assertion throws on the http2 stream's event tick (not inside any caller's try), it escapes as an uncaught exception and crashes the process.

The sibling handlers already treat a post-completion delivery as expected and guard against it:

// onEnd
if (state.responseReceived) {
  if (!request.aborted && !request.completed) { state.pendingEnd = true }
}

// onTrailers
if (request.aborted || request.completed) { return }

onResponse is the only one of the three missing the completed guard — that asymmetry is the bug.

Fix

Add the same request.completed guard the other handlers use:

-  if (request.aborted) {
+  if (request.aborted || request.completed) {
     releaseRequestStream(stream)
     return
   }

How it shows up

We hit this in production on undici@7.22.0 (same defect there: the v7 'response' handler guards only request.aborted, and the method was named onHeaders, which also assert(!this.completed)). The crash:

AssertionError [ERR_ASSERTION]: assert(!this.completed)
  at Request.onHeaders (undici/lib/core/request.js)
  at ClientHttp2Stream.<anonymous> (undici/lib/dispatcher/client-h2.js)  // the 'response' handler
  at ... node:internal/http2/core

It reproduces under load when many requests are multiplexed over shared, long-lived h2 sessions (HTTP/2 connection coalescing to a CDN edge), where server-initiated GOAWAY / refused-stream churn causes frequent concurrent stream teardowns — i.e. exactly the completion-vs-'response' race this guard handles. On the default per-origin HTTP/1.1 path the client-h2.js code is never exercised, so it only manifests with allowH2: true.

Note on a test

This is a client-side event-ordering race; I couldn't construct a deterministic, non-flaky regression test against a real http2 server without contriving the stream's event emission. The change mirrors the existing onEnd/onTrailers guards exactly. Happy to add a test if a maintainer can point me at the preferred way to drive a post-completion 'response' on the request stream.

This affects main (v8.5.0) and v7.x — flagging in case a backport is wanted.