[maruthang]

This relates to...

Fixes #4735

Rationale

Since undici 7.16.0 (PR #4521, commit 909a5845), the ErrorEvent dispatched on a WebSocket when the opening handshake fails carries an empty string as its message. The old behavior surfaced a descriptive reason (e.g. "Received network error or non-101 status code."), which is what consumers — and the WPT / nodejs test fixtures — rely on to diagnose connection failures.

The regression comes from WebSocket#onSocketClose unconditionally constructing new TypeError(reason) where reason defaulted to "", discarding the descriptive reason that failWebsocketConnection had already produced internally.

This change restores the pre-regression behavior by plumbing the failure reason (and cause, when present) from failWebsocketConnection through to #onSocketClose, so the dispatched ErrorEvent once again has a non-empty message and its error is a TypeError with a meaningful message (and a cause when the underlying failure provides one). The error type remains TypeError, consistent with maintainer guidance on the duplicate issue #4625.

Changes

• lib/web/websocket/connection.js: failWebsocketConnection now stores { code, reason, cause } on a new handler.closeInfo slot before invoking the socket close path, so the reason is not lost by the time #onSocketClose runs.
• lib/web/websocket/websocket.js: handler typedef and initialization gain a closeInfo slot; #onSocketClose consumes it to build an ErrorEvent whose message matches the pre-regression string and whose error is a TypeError carrying that same message (plus cause when available).
• test/websocket/issue-4735.js: new regression test that opens a WebSocket to a closed port and asserts the error event's message is a non-empty string.

Features

N/A

Bug Fixes

• Bug Fixes: Populate ErrorEvent message/error with the underlying failure reason on WebSocket connect failures (WebSocket emits error event with an empty message when cannot open connection #4735).

Breaking Changes and Deprecations

None.

Status

• I have read and agreed to the Developer's Certificate of Origin
• Tested
• [S] Benchmarked (optional)
• [S] Documented
• Review ready
• In review
• Merge ready

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.12%. Comparing base (ec60a7c) to head (87800b3).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5079      +/-   ##
==========================================
+ Coverage   93.10%   93.12%   +0.02%     
==========================================
  Files         110      110              
  Lines       35807    35824      +17     
==========================================
+ Hits        33339    33362      +23     
+ Misses       2468     2462       -6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[KhafraDev]

This just isn't good code, and we're already not following the spec by emitting an ErrorEvent.

[maruthang]

Understood @KhafraDev — thanks for the direction. If the ErrorEvent emission itself is the non-conformance, then patching its message is painting over the real problem. I won't reopen; if I look at this area again it'll be after understanding what spec-conformant error reporting should look like here, and I'll raise a discussion issue first rather than jumping to a PR.

Sorry for the noise.