Using MessageChannel pulls in undici inappropriately #57581
Description
Activity
cc @nodejs/undici I think also typescript has the same issue since amaro lazy loads a wasm
MessageEvent is part of the HTML standard and it's at basis of WebSocket.
https://html.spec.whatwg.org/multipage/comms.html
That's why the global comes from undici. What I'm a bit puzzled about is why for non-spec compliant objects we are using it in
.node/lib/internal/worker/io.js
Line 94 in c3b6f94
This appears to come from #52370.
Wdyt @KhafraDev?
What I'm a bit puzzled about is why for non-spec compliant objects we are using it in
It was exposed globally where the real issue arose from, when
<message event from websocket> instanceof MessageEventwould be false. It was not a good implementation, and since undici already had a fully spec-compliant, faster implementation, it was easier to replace node's with undici's.The only place where MessageEvent is mentioned in our docs is https://nodejs.org/api/worker_threads.html#broadcastchannelonmessage.
I'm a bit puzzled why we use it here to begin with. @jasnell @addaleax do you recall?
Puzzled about using it where exactly?
About why our
MessagePortandMessageChannelare using the spec-compliantMessageEvent. Do you recall what the design motivation was?I think we can add a fallback if there is no fetch/undici for
MessageEvent.well,
MessagePortwould have had a separateMessageEventoriginally since that predates the introduction of undici and WebSockets but I guess it got replaced at some point with the undici one. The code in worker/io.js was updated about 11 months ago was updated (#52370) to switch to using undici'sMessageEventrather than the original implementation that still exists in the runtime inlib/internal/per_context/messageport.js.There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale
Issues and PRs exempt from automated stale handling. label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.This is still an issue, not stale.
I cant reproduce it on node 24. On node22 I can.
Nevermind then, I guess it got silently fixed. v24 seems to have fixed the issue, I only tested against v22.
Version
v22.13.1
Platform
Subsystem
worker_threads
What steps will reproduce the bug?
Run this command:
node --jitless -e 'const { port1, port2 } = new MessageChannel(); port1.addEventListener("message", () => {}); port2.postMessage(null);'or run this script with
--jitlessHow often does it reproduce? Is there a required condition?
Every time
What is the expected behavior? Why is that the expected behavior?
No exception should be thrown,
undicishould not be loaded when fetch is not needed.What do you see instead?
Additional information
I believe this is due to constructing the
MessageEvent, which appears to come fromundici:node/lib/internal/worker/io.js
Line 98 in 4006d5e