BroadcastChannel doesn't fill in useful MessageEvent fields like source, or ports

[jdmarshall]

Version

No response

Platform

This makes it difficult to use BroadcastChannel to set up coordinations between worker threads unless they share the same supervisor. 

Which is problematic for things like caching or telemetry.


MessageEvent {
  type: 'message',
  defaultPrevented: false,
  cancelable: false,
  timeStamp: 444.018666
}

ports, source are empty strings.

Subsystem

node:worker_threads

What steps will reproduce the bug?

        const util = require('util');
	const channel = new BroadcastChannel('example');

	if (isMainThread) {
		channel.addEventListener('message', evt => {
			console.log(util.inspect(evt)); // breakpoint here
		});
	} else {
		channel.postMessage('hello');
        }

How often does it reproduce? Is there a required condition?

Always. Seems to be by design, and the design may have drifted from the current web standards over time.

What is the expected behavior? Why is that the expected behavior?

That I get some metadata

What do you see instead?

empty string, empty array.

Additional information

No response

[jdmarshall]

I believe if this were weaved into the active work on https://nodejs.org/api/worker_threads.html#workerpostmessagetothreadthreadid-value-transferlist-timeout

it would make that feature much more powerful, because BroadcastChannels could then be used to coordinate discovery and then private messagePorts could be established between workers that need them.

[jdmarshall]

Implementing the fields defined by https://developer.mozilla.org/en-US/docs/Web/API/BroadcastChannel/message_event

Would likely negate the need for the postMessageToThread() functionality entirely. You just need a shared presence BroadcastChannel to allow workers that need to talk to each other to be introduced, instead of messaging threadIds at random.

[github-actions]

This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

[jdmarshall]

Still would be useful.

[SudhansuBandha]

@jdmarshall if we try to run these additional lines of code in your provided sample
console.log(evt.ports); console.log(evt.source);
then the output is
[] null
Based on this it looks like these fields are already available to use. May I know is there any specific implementation whitch is not present atm apart from missing fields as described that will address this issue?

[jdmarshall]

Based on this it looks like these fields are already available to use.

I don't understand how the absence of information equates to being 'available to use'. You have to populate a field in order for the field to be useful. There is no data propagation going on which makes it difficult for one worker to find another. It's not really a broadcast channel by the usual definition of broadcast if all data must come from and return to the main thread. That's just a multiplexed channel. Broadcast would be 2 classes of workers being able to talk to each other. Which would require information such as the source to be populated so a response could be formulated.

[SudhansuBandha]

We can reachout to maintainers for more clarity on this.

What information is expected to be exposed through event.source for BroadcastChannel messages?
a sender threadId?
b something else?

What should event.ports contain in this context?
a transferred MessagePorts?
b remain empty for compatibility with current browser behavior?

Is the primary goal of this issue?
a alignment with the Web Platform semantics of MessageEvent, or
b enabling worker discovery and direct worker-to-worker communication patterns in Node.js?

@nodejs/workers

[jdmarshall]

TL;DR: Populate the source field.

It's been a real minute and I need to look around to see if I still have my test case anywhere.

I understand why event.ports is tricky, because for ports to be shared the broadcast mechanism would have to have been built down at the port level. You can't have 5 workers writing to the same port. But there's not a way to sendMessage to a particular worker because that information is not there, which is why the postMessageToThread functionality is presumably being worked on which is not great, one reason being is that finding the threadId is still problematic, so you have to use the broadcast channel to do rendezvous anyway. Using three APIs to accomplish a task two should be able to do is messy.

What I have is one worker aggregating data to send out over a socket. Data aggregation of that sort and volume needs to be evicted from the main thread so that the amount of time the event loop blocks is not proportional to the number of workers. That screws up vertical scaling substantially, and P99 times will show massive intermittent spikes, which could trigger alarms. No good. I'm thinking particularly of telemetry data, but any system architecture that uses heterogenous workers in order to avoid cooperative multitasking's limitations with latency tails will run into this problem.

So what I would prefer is that when a worker starts, it uses the BroadcastChannel only to perform a rendezvous to exchange ports between the sender and the receiver. I am here, send me a port for this class of traffic, got it, let's rock. Then the peers don't need to hear traffic intended for each other, except the rendezvous which should be very, very infrequent. But the missing fields prevent that from happening.

[aduh95]

/cc @nodejs/workers

[SudhansuBandha]

If exposing the sender's threadId via event.source would address the use case, I'd be interested in exploring a PR for it (along with appropriate tests), assuming this approach aligns with the intended design and maintainers are open to it.