doc: unclear conditions under which Worker's 'messageerror' is emmited

[naz]

• Version: 14.15.1

• Platform: Linux 5.4.0-54-generic Proposal: Comment all the code #60-Ubuntu SMP Fri Nov 6 10:37:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

• Subsystem: worker_threads

Location

Section of the site where the content exists

Affected URL(s):

• https://nodejs.org/api/worker_threads.html#worker_threads_event_messageerror

Description

Concise explanation of the problem

It is unclear from the documentation how one could cause/simulate messageerror to be emitted by the Worker. It would be useful to understand the conditions when it happens and also be able to simulate such situations when testing code. A concrete example when this would be helpful is in bree codebase, where test coverage has been skipped because there's no way to simulate this event.

---

• I would like to work on this issue and
  submit a pull request.

[naz]

To be clear, I'm happy to update the docs and provide a PR. Just lacking enough knowledge on the internal c++ workings of workers.

[Trott]

@nodejs/workers

[jasnell]

pinging @addaleax (whom I believe has the most context / understanding of this part of the code)

[benjamingr]

Look at parallel/test-crypto-key-objects-messageport.js and test/parallel/test-worker-message-port-transfer-filehandle.js

[addaleax]

It is unclear from the documentation how one could cause/simulate messageerror to be emitted by the Worker.

Yeah, that’s a fair point. Part of why this was was left appear unclear is that it is also unclear (to me) in the HTML spec when this event would be emitted in the browser implementations.

Currently, this event is emitted when there is an error occuring while instantiating the posted JS object on the receiving end, where there would otherwise be no way to communicate that situation.

The examples pointed to by @benjamingr are for situations in which Node.js API objects (not JS built-ins) are received in a vm.Context, which is currently an environment in which Node.js APIs are not available. That is a known limitation for now, rather than something that is inherent to the way we build APIs. It’s also not a condition under which messageerror would be emitted on a Worker, only MessagePorts (because there’s no way to create a Worker inside a vm.Context).

You could probably make some of the deserialization methods throw an exception in some way, and generate the event through that, for example by messing with the prototypes of Node.js API objects, but ultimately, I don’t think there’s any good way to generate these events through the public API currently.

I can’t think of any reason why deserializing a message should fail once it has been posted, except for limitations in Node.js’ builtins, so, for testing, I would currently recommend just to emit the events directly.