Maybe I have this wrong but for my statement:

• debuggee will be my "debug adapter server" (aka the process separate to vscode handling DAP messages) (it's the DAP equivalent to a Language Server)
• debug adapter is in a vscode extension (aka the client) - I have a NamedPipeDebugAdapter.

The disconnect request is a very odd request to me because it not only tells the debuggee to terminate (if it was a launch request), but it also requires a response back to the debug adapter.

It's very easy to fall into a situation where there's a race condition between responding to the message and the debuggee terminating itself.

If the debuggee terminates itself first, then it never has a chance to respond to the disconnect message that the client sent... and so vscode shows an error toast saying "timeout 1000ms passed".

If the debuggee responds to the message first, and I'm using a named pipe or a tcp port as the communication layer, there's a possible race condition where launching the debuggee again attaches to the port or pipe that's in the process of being closed rather than a newly created process.

Do you have any guidance here? My biggest wish would be that the disconnect request should really be 'fire and forget' from the vscode side to prevent DAP implementors from hitting this race condition.