Currently, the worker_launch function will register the background worker and wait for the process to start using WaitForBackgroundWorkerStartup.
Problem
The procedure above do not wait for the background worker to bind to the port and start listening on it, which means that if any of these fail, there is no indication to the session that issues the command that this failure happened. This complicates testing and also make the usability worse since it can look like the system started the background workers, but they actually exited quite soon after as a result of an error.
Solution
Do not return from the worker_launch function unless the background worker has properly bound the ports and has started listening on the socket.
Pass back any errors occurring before this point is reached to the dispatching session and print this as an error.
Situation
Currently, the
worker_launchfunction will register the background worker and wait for the process to start usingWaitForBackgroundWorkerStartup.Problem
The procedure above do not wait for the background worker to bind to the port and start listening on it, which means that if any of these fail, there is no indication to the session that issues the command that this failure happened. This complicates testing and also make the usability worse since it can look like the system started the background workers, but they actually exited quite soon after as a result of an error.
Solution
worker_launchfunction unless the background worker has properly bound the ports and has started listening on the socket.