More Descriptive Error When WebSocket Closes with Code 1006

[adiwajshing]

Bug Description

The new WebSocket library is pretty great, but when a WebSocket connection closes without completing the control frame exchange, it spits out an empty message TypeError, which isn't very descriptive of the problem and appears as an error message that accidentally slipped through the deployment. The exact line of code is:

undici/lib/web/websocket/websocket.js

Lines 589 to 591 in dc5802d

	fireEvent('error', this, (type, init) => new ErrorEvent(type, init), {
	error: new TypeError(reason)
	})

Reproducible By

Haven't written exact steps to reproduce, but it happens occasionally on connection closure.

Expected Behavior

Perhaps a better description of the connection closure in the ErrorEvent? "Connection closed with code: xyz"
Also imo, would be better to use a plain Error rather than a TypeError.

If this is something the team feels would be a good addition, happy to make a PR

Logs & Screenshots

TypeError\n    at #onSocketClose (node:internal/deps/undici/undici:13908:20)\n    at TLSSocket.onSocketClose (node:internal/deps/undici/undici:13611:72)\n    at TLSSocket.emit (node:events:520:35)\n    at node:net:346:12\n    at TCP.done (node:_tls_wrap:649:7)

Environment

Ubuntu 20, NodeJS 24.0

[KhafraDev]

Perhaps a better description of the connection closure in the ErrorEvent? "Connection closed with code: xyz"

In this case you would lose the reason the connection error'd. I'd like to know how we're generating an empty reason before changing the default error message as it could be a bug, which I'd rather fix than patch over.

Also imo, would be better to use a plain Error rather than a TypeError.

It should stay as a TypeError. Web specs typically default to TypeErrors over plain errors, so we mimic it.

[adiwajshing]

It should stay as a TypeError. Web specs typically default to TypeErrors over plain errors, so we mimic it.

Fair enough.

In this case you would lose the reason the connection error'd. I'd like to know how we're generating an empty reason before changing the default error message as it could be a bug, which I'd rather fix than patch over.

So if you see these lines -- it appears that the reason is just never set, the empty string set on L565 is passed into the TypeError on L590. Might just be a bug if that's not intended behaviour.

[KhafraDev]

So if you see these lines -- it appears that the reason is just never set, the empty string set on L565 is passed into the TypeError on L590. Might just be a bug if that's not intended behaviour.

Yeah, that's the easy part. I want to know when the socket can close either without a close frame or with an error, which is when the reason wouldn't be set.