Cannot read properties of null (reading 'destroyed')

[ktaekwon000]

Bug Description

Very occasionally, undici will throw this error as an uncaught rejection, causing the node process to crash.
The stack trace is as follows:

TypeError: Cannot read properties of null (reading 'destroyed')
    at _resume (/node_modules/undici/lib/client.js:1429:16)
    at resume (/node_modules/undici/lib/client.js:1334:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:81:21)

Reproducible By

I am unable to replicate this issue consistently, but this issue pops up frequently, sometimes multiple times in a week.

Environment

Debian 12.4, node v18.19.0, undici 6.5.0

Additional context

    if (!socket && !client[kHTTP2Session]) {
      connect(client)
      return
    }

    if (socket.destroyed || socket[kWriting] || socket[kReset] || socket[kBlocking]) {
      return
    }

The error occurs in the condition of the second if clause, where socket is null. I believe that

1. client[kHTTP2Session] is not being set to null on socket close, despite socket being set to null. I see another function in client.js, onUpgrade, where socket is being set to null but client[kHTTP2Session] is not touched, but I believe this should not be called when client[kHTTP2Session] is truthy.
2. Perhaps first if clause should be rolled back to if (!socket) { to account for null socket even if client[kHTTP2Session] is truthy, so that http2 connect logic is triggered if socket is null. I'm not entirely sure of the reason this if clause was changed.

[metcoder95]

Hmm, good catch; the HTTP2Session depends on the socket, one cannot exist without the other; matter of fact there are several places that might need to be refactored better to account for the mix of the HTTP2 session and socket.

Do you think you can provide an
Minimum Reproducible Example to reproduce your problem? I know you said might be hard, but something we can run to debug it (doesn't matter it only works the nth time)

[ktaekwon000]

I suspect that an environment that drops TCP connections randomly could cause this error, but I've tried and failed to write a MRE for it 😅