I think our current implementation of Launch and Attach Request are wrong.
It is meant to acknowledge if it a launch or an attach. the main start of debugee should be after configurationDone request from the client.
This should eliminate the data race of setting the breakpoint and stopOnEntry (in our current implementation of launch this is checked when we are are at configuration done). If for some reason there is a large delay from the LaunchRequest to the configurationDoneRequest, we would miss it entirely. Same goes for setting breakpoints (Occasionally I have witnessed this happen).
Relevant info from the specification link
Launch Sequencing
There are three main building blocks we’ve discussed to create a debugging session:Initialization, via the initialize request,
Configuration of breakpoints and exceptions during the configuration stage, and
Starting the debugger, via a launch or attach request.
Initialization happens first, and the debug adapter must respond to the initialize request with any capabilities before any further communication can take place. At any point after the client receives the capabilities, it sends a launch or attach request.Once the debug adapter is ready to receive configuration from the client, it sends an initialized event to the client. As described above, the client sends zero or more configuration-related requests before sending a configurationDone request.
After the response to configurationDone is sent, the debug adapter may respond to the launch or attach request, and then the debug session has started.
This could solve the problem because we know when exactly the debugee is started. the parallel part of initalizing and launching is handled before the debuggee is started, so It does not send any event that the client may not be ready to handle.
To double check I reconfirmed this with some implementation of protocol.