Repository navigation
discussion about how to fix child_process 'spawn' not ready to send messages on ESM #41134
Description
Activity
- changed the title
[-]discussion about how to fix child_process 'spawn' event is emitted too soon on ESM[/-][+]discussion about how to fix child_process 'spawn' not ready to send messages on ESM[/+]on Dec 10, 2021 Seems like a fine idea to me but would want to hear what @nodejs/modules and/or @nodejs/child_process folks might have to say about it.
Reacted by Erick Wendel, Weriton T. Machado, Kaique da Silva and Alan Jones RiosI'd prefer if we could queue things because this problem isn't unique to ESM and I've seen it in the long past using purely CJS and callbacks.
Reacted by Weriton T. Machado, Kaique da Silva and Matteo CollinaI'd prefer if we could queue things because this problem isn't unique to ESM and I've seen it in the long past using purely CJS and callbacks.
I think I didn't get it. What do you mean by queue things?
I'd prefer if we could queue things because this problem isn't unique to ESM and I've seen it in the long past using purely CJS and callbacks.
I don't get it too... do you can explain please?
@gabrielsimas MessagePort will queue messages (events) and wait for a listener before draining the messages. The problem in this issue is that event listeners which are used in
child_processare not queueing messages and fire messages that the child process has loaded prior to the child process attaching any listeners to handle events.Reacted by Erick WendelI spoke to @addaleax and she suggested a behavior that is closer to what MessagePorts expose, which is queueing up messages until a message listener is installed.
This was my first thought
Reacted by Erick Wendel@gabrielsimas MessagePort will queue messages (events) and wait for a listener before draining the messages. The problem in this issue is that event listeners which are used in
child_processare not queueing messages and fire messages that the child process has loaded prior to the child process attaching any listeners to handle events.niiice! It's the same strategy @addaleax suggested on the post, right?
Reacted by Anna HenningsenReacted by Kaique da SilvaYou have a reproduction of the behavior @ErickWendel?
Or the behavior is the same on the related content you shared?
Or the behavior is the same on the related content you shared?
Yes, Actually they already had reproduced the behavior at all of the issues I mentioned in the post. See this one #39140
Reacted by Kaique da SilvaI'd prefer if we could queue things because this problem isn't unique to ESM and I've seen it in the long past using purely CJS and callbacks.
This is the way to go
Reacted by Erick Wendel11 remaining items
- added a commit that references this issue
on Dec 30, 2021 - added a commit that references this issue
on Jan 14, 2022 For future searchers: This has been resolved and released in v17.4.0. (🎉)
Reacted by Philipp A., Nico Jansen, David Fonseca, Henrique Vieira and Samuel A. Souza- added a commit that references this issue
on Jan 31, 2022 - added a commit that references this issue
on Feb 1, 2022 Also released in 16.14.0 if you're on LTS.
Reacted by Erick Wendel, Viliam Elischer, Noel Varanda and Henrique Vieira- added a commit that references this issue
on Apr 23, 2022 - added a commit that references this issue
on Apr 25, 2022 - added a commit that references this issue
on May 1, 2022
BTW: I'd like to help fixing this bug 🤩
Is your feature request related to a problem? Please describe.
There's a current issue on spawn's child processes using ES modules mentioned in those issues (#37782, #39140, #39140, #34785, and help/issues/1383 ).
When you fork a file and immediately use the
.sendevent. The child process doesn't receive messages because it's not ready yet.So we need to make a workaround. The child emits an event, the parent waits for
.on('message',we check the message and then we start sending messages to the child.Describe the solution you'd like
My plan initially was to add an event like
child.on("readyto specify when we can start sending messages to the child process.I spoke to @addaleax and she suggested a behavior that is closer to what
MessagePortsexpose, which is queueing up messages until a message listener is installed.I know that it would increase implementation complexity a bit, but it would be very helpful for avoiding pitfalls like the ones linked here
What do you think? Any ideas of what could we do?