You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fork child process does not receive message event when using ES modules #34785
im trying to have two way messaging between child process and the parent process, the parent process works as expected it sends and receives messages from child process, but the child process is only able to send message and not receive them
ive enabled ES6 modules from package.json using this key-value "type": "module"
app.js
import { fork } from 'child_process';
const child = fork('./script.js');
child.on('message', msg => console.log('msg from child :', msg));
child.send({ msg: 'parent' }, () => console.log('parent sent msg'));
script.js
process.on('message', msg => console.log('msg from parent :', msg));
process.send({ msg: 'child' }, () => console.log('child sent msg'));
expected behavior
parent sent msg
msg from child : { msg: 'child' }
msg from parent : { msg: 'parent' }
child sent msg
output recieved
parent sent msg
msg from child : { msg: 'child' }
child sent msg
Additional information
this issue is not present while using commonJs modules (ie: require('child_process') )
same issue closed without bug fix, nodejs/help#1383
although the workaround would be to call the child.send in the next tick like shown below, this is not homologous to the commonJs behavior
changed the title [-]fork child process does not receive message event when using ES6 modules[/-][+]fork child process does not receive message event when using ES modules[/+]on Aug 15, 2020
I think that's explained by the asynchronous nature of ES module loading.
Your script has a race condition, it's just less likely to trigger with (synchronous) CJS. The solution is to have the child notify the parent that it's ready for operation and only then send the message.
I'm going to close this as a wontfix but I can move the issue to nodejs/help if you have follow-up questions.
Reacted by dheeraj br, Raj Thakar, Nico Jansen and Zirafnik
@bnoordhuis i believe there is no built-in event to notify the parent, cluster has 'online' event to notify when a fork process has started. a feature where maybe the child process can implicitly emit an event once its started, if that's plausible i can follow-up, if not we can end this here.
Not built-in, no, but there couldn't be - node doesn't know when your script is ready. Call process.send('ready') in the child and make the parent wait for that event before it starts sending messages of its own.
Reacted by João Távora, Frank Lemanschik and Patrick Staarink
Activity
[-]fork child process does not receive message event when using ES6 modules[/-][+]fork child process does not receive message event when using ES modules[/+]bnoordhuis commentedon Aug 15, 2020
I think that's explained by the asynchronous nature of ES module loading.
Your script has a race condition, it's just less likely to trigger with (synchronous) CJS. The solution is to have the child notify the parent that it's ready for operation and only then send the message.
I'm going to close this as a wontfix but I can move the issue to nodejs/help if you have follow-up questions.
dheeraj-br commentedon Aug 16, 2020
@bnoordhuis i believe there is no built-in event to notify the parent, cluster has 'online' event to notify when a fork process has started. a feature where maybe the child process can implicitly emit an event once its started, if that's plausible i can follow-up, if not we can end this here.
bnoordhuis commentedon Aug 16, 2020
Not built-in, no, but there couldn't be - node doesn't know when your script is ready. Call
process.send('ready')in the child and make the parent wait for that event before it starts sending messages of its own.joaotavora commentedon Mar 20, 2021
Right. This works. But I think at least one should update the documentation (https://nodejs.org/api/child_process.html#child_process_subprocess_send_message_sendhandle_options_callback) to call attention to this very elusive gotcha.