HTTP/2: TypeError: Cannot read properties of null (reading 'onResponseError')

[slagiewka]

Bug Description

When we allowH2 on our canary prod deployment, the process is inevitably going to crash on 8.4.x.
I can't remember if I tested on 8.3, but previous 8.x releases did not crash.

Reproducible By

Not entirely sure, but we only get that crash when we toggle allowH2 explictly (disabled otherwise and doesn't crash).

We use undici.request and a pre-configured Agent.

Expected Behavior

No crashes when enabling HTTP/2.

Logs & Screenshots

Process crashing with:

/usr/src/app/node_modules/undici/lib/core/util.js:843
    request.onResponseError(err)
            ^

TypeError: Cannot read properties of null (reading 'onResponseError')
    at Object.errorRequest (/usr/src/app/node_modules/undici/lib/core/util.js:843:13)
    at /usr/src/app/node_modules/undici/lib/dispatcher/client.js:398:14
    at new Promise (<anonymous>)
    at [destroy] (/usr/src/app/node_modules/undici/lib/dispatcher/client.js:394:12)
    at Client.destroy (/usr/src/app/node_modules/undici/lib/dispatcher/dispatcher-base.js:145:19)
    at /usr/src/app/node_modules/undici/lib/dispatcher/dispatcher-base.js:109:14
    at new Promise (<anonymous>)
    at Client.destroy (/usr/src/app/node_modules/undici/lib/dispatcher/dispatcher-base.js:108:14)
    at /usr/src/app/node_modules/undici/lib/dispatcher/dispatcher-base.js:97:24
    at runNextTicks (node:internal/process/task_queues:65:5)
Emitted 'error' event on Client instance at:
    at Object.errorRequest (/usr/src/app/node_modules/undici/lib/core/util.js:846:12)
    at /usr/src/app/node_modules/undici/lib/dispatcher/client.js:398:14
    at new Promise (<anonymous>)
    at [destroy] (/usr/src/app/node_modules/undici/lib/dispatcher/client.js:394:12)
    at Client.destroy (/usr/src/app/node_modules/undici/lib/dispatcher/dispatcher-base.js:145:19)
    at /usr/src/app/node_modules/undici/lib/dispatcher/dispatcher-base.js:109:14
    at new Promise (<anonymous>)
    at Client.destroy (/usr/src/app/node_modules/undici/lib/dispatcher/dispatcher-base.js:108:14)
    at /usr/src/app/node_modules/undici/lib/dispatcher/dispatcher-base.js:97:24
    at runNextTicks (node:internal/process/task_queues:65:5)

Node.js v26.3.0

Environment

Undici v8.4.1
Node v26.3.0 (distroless container)

Additional context

[mcollina]

Thanks for reporting!

Can you provide steps to reproduce? We often need a reproducible example, e.g. some code that allows someone else to recreate your problem by just copying and pasting it. If it involves more than a couple of different file, create a new repository on GitHub and add a link to that.

[slagiewka]

I wasn't quite sure what's the issue, but GPT-5.5 comes to the rescue. It seems to be possible whenever a connection gets closed but another stream is also waiting for response.

repro.mjs

import { createServer } from "node:http2";
import { once } from "node:events";
import { setTimeout } from "node:timers/promises";
import { Agent } from "./index.js"; // or from "undici";

const server = createServer();

server.on("stream", async (stream, headers) => {
  if (headers[":path"] === "/slow") {
    await setTimeout(50);
    stream.respond({ ":status": 200 });
    stream.end("slow");
  } else {
    stream.close();
  }
});

server.listen(0);
await once(server, "listening");

const origin = `http://localhost:${server.address().port}`;
const dispatcher = new Agent({
  connections: 1,
  useH2c: true,
});

const slow = dispatcher
  .request({ origin, path: "/slow", method: "GET" })
  .then(async (res) => res.body.text());

const bad = dispatcher
  .request({ origin, path: "/bad", method: "GET" })
  .catch((err) => {
    console.log("bad request failed as expected:", err.name, err.message);
  });

await bad;
console.log("slow result:", await slow);

await dispatcher.close();

const { promise, resolve } = Promise.withResolvers();
server.close(resolve);
await promise;

Stack trace looks identical.