Bull: Inspector address already in use when processing job

[weeco]

As suggested in the readme I am trying to run my process function in a seperate process. Therefore I've created a new file which exports my function. However it seems like every time it starts processing this function my inspector crashes (I don't see any log messages in my terminal anymore):

const refreshPlayerProfileQueue = new Queue('find new player')
refreshPlayerProfileQueue.process('/app/players/jobs/refresh-player-profiles.js')
refreshPlayerProfileQueue.add({}, { repeat: { cron: '* * * * *' } })

Starting inspector on 127.0.0.1:17989 failed: address already in use
Child process exited 30492 12 null

Is that a normal behaviour?

[manast]

No idea. But does it work without the inspector?

[weeco]

Yes it does work, I don't get this message if I define my job processor in the same file. I assume it's happening because it's being processed as it's own process? I am using VSCode + Node v 8.5.0 and anyone with this environment should be able to reproduce the problem I guess?

[manast]

I guess there is something incompatible with the inspector, at least VSCode, and the way the process are created, although this is using standard nodejs without external dependencies, could be a bug in nodejs or the inspector, I will need to investigate more. A piece of advice if you want to test your external processor functions, just call the process directly from your unit tests, that way you should also be able to debug with the inspector without any problems.

[weeco]

I just wanted to test my external processor functions by running them with my vscode debugger.

[maxerbox]

Thats due to vscode, which multi process debugging is quite complicated >
https://github.com/Microsoft/vscode/issues/3201. I already had the same
situation. Node.js is trying to create a new process on the same inspect port, because the master command line args are passed to the children.
The best thing to do is to debug on one process, and then split them in a
production environment

[weeco]

Hm that really sucks for development, how do others handle this? I thought VSCode is one of the most popular IDEs for Node.js, I am surprised that I am the first one reporting this issue

[laukaichung]

I have the same problem with webstorm.
Webstorm has a way of debugging multiple processes by adding a command line argument (reference):
child_process.exec('node --debug=8787 ' + __dirname + '/childProcess.js');
Could it be possible to set a debugging port like that in bull?

[manast]

We are using fork it seems as it can be given a execPath as an option, in that case it may work, of course we would only like enable this in debug mode:
https://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options

[manast]

This is where the child process is forked: https://github.com/OptimalBits/bull/blob/master/lib/process/child-pool.js#L19

[Freundschaft]

I am pretty sure this is directly related to this issue: https://github.com/nodejs/node/issues/9435
basically nodejs handles child processes and inspect not very nicely and causes this setup to break

[mihailstefanov]

"autoAttachChildProcesses": true