Skip to content

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

Description

@naz
  • Version: 14.15.1
  • Subsystem: worker_threads

Location

Section of the site where the content exists

Affected URL(s):

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.

Activity

  1. added
    docIssues and PRs related to Node.js documentation.
    on Dec 1, 2020
  2. naz commented on Dec 1, 2020

    @naz
    Author

    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.

  3. added
    workerIssues and PRs related to the worker_threads module and Worker API.
    on Dec 2, 2020
  4. Trott commented on Dec 2, 2020

    @Trott
    Member

    @nodejs/workers

  5. jasnell commented on Dec 7, 2020

    @jasnell
    Member

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

  6. benjamingr commented on Dec 7, 2020

    @benjamingr
    Member

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

  7. addaleax commented on Dec 7, 2020

    @addaleax
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    docIssues and PRs related to Node.js documentation.workerIssues and PRs related to the worker_threads module and Worker API.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions