worker: populate BroadcastChannel MessageEvent source

[SudhansuBandha]

Populate the MessageEvent source property with the sender's worker thread ID for BroadcastChannel messages originating from worker threads.

Fixes: #59053

[jdmarshall]

In the MDN documentation, https://developer.mozilla.org/en-US/docs/Web/API/MessageEvent/source

The source read-only property of the MessageEvent interface is a MessageEventSource (which can be a WindowProxy, MessagePort, or ServiceWorker object) representing the message emitter.

The threadId might be sufficient to work with the new API you folks were working on but I'm wondering if there's a technical limitation that makes diverging from the web api an absolute necessity? Ideally this would be the Worker Object, since one could immediately invoke postMessage() for any rendezvous coordination necessitated by the broadcast. With that in mind a MessagePort would also work if that's available, but I'm guessing that is not...

[jasnell]

This is a breaking change making this a semver-major. It will need doc updates as well. I think we should instead try to find a way of doing this so that it's not a breaking change

[SudhansuBandha]

Thanks for the review, @jasnell. I agree that changing MessageEvent.source makes this a semver-major change. Do you have any particular approach in mind for exposing the sender information while preserving the existing semantics of MessageEvent.source? I'd like to make sure I'm exploring all feasible directions that best align with Node's API design.

[jdmarshall]

@jasnell Source currently resolves to null. Why would this a breaking change when there is nobody in the forest to hear the tree fall?

[SudhansuBandha]

node/deps/undici/undici.js

Lines 14727 to 14737 in 8fec65d

	static createFastMessageEvent(type, init) {
	const messageEvent = new _MessageEvent(kConstruct, type, init);
	messageEvent.#eventInit = init;
	messageEvent.#eventInit.data ??= null;
	messageEvent.#eventInit.origin ??= "";
	messageEvent.#eventInit.lastEventId ??= "";
	messageEvent.#eventInit.source ??= null;
	messageEvent.#eventInit.ports ??= [];
	return messageEvent;
	}
	};

Will it be feasible to add a Node Specific extension on MessageEvent (ex.- event.sender). This would avoid a breaking change while still allowing Node to expose sender information through a separate property.
cc. @addaleax @mcollina @jasnell

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.23%. Comparing base (0032189) to head (e392e56).
⚠️ Report is 10 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff            @@
##             main   #64334    +/-   ##
========================================
  Coverage   90.23%   90.23%            
========================================
  Files         741      741            
  Lines      241194   241355   +161     
  Branches    45432    45467    +35     
========================================
+ Hits       217640   217798   +158     
+ Misses      15129    15128     -1     
- Partials     8425     8429     +4     

Files with missing lines	Coverage Δ
lib/internal/worker/io.js	99.21% <100.00%> (+0.02%)	⬆️

... and 32 files with indirect coverage changes

🚀 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.

[SudhansuBandha]

I have created an extension of the Undici based MessageEvent on Node to provide sender as a new property that will represent threadId in these message events. I have updated docs for the same as well as requested by @jasnell
Hope that this won't be leading to any breaking changes.

[mcollina]

I'm not sure this is needed. The sender can always attach their own id if needed

[jdmarshall]

The API to send messages to a threadId is labeled experimental. The request was for the worker object to be set to source, so that messages could be sent directly, the same way web workers can.

[jdmarshall]

This PR does not fix #59053

It does something else that does not achieve feature parity with the HTML5 spec and is functionally unfit for purpose.

[jdmarshall]

I have updated the description of the ticket. After a long architecture conversation with another maintainer on the prometheus project, I've finally been able to articulate the problem here.

Which is that there is currently no mechanism for composing Workers. If you create some workers for one task, you can manage them as interchangeable. If they need to ask any questions, they have to ask you. That's fine. But not fine when your organization has a second set of Workers with a different task. Now they have to talk to each other across Conway's Law boundaries and we have that law because not following it always ends in shouting and either tears or bloodshed.

So, if I want to move caching to workers, and telemetry or image processing to other workers, and if they ever need to talk to each other, they need an opt-in mechanism to arrange their own communication channel between them, rather than calling a common parent and having them make the introduction. There isn't even a way in NodeJS to enumerate all of the currently running workers, so I can't write a module that goes looking around for your workers. Those two pieces of code have to be directly coupled. And they might already be 2 layers of separated in the system architecture when we figure it out. Which is a long way to say, "not composable".

As near as I can tell, that's the whole reason BroadcastChannel exists. You just need two subsystems to know of a topic
in common that they want to discuss. Done.