from the documentation:

"After a successful launch or attach VS Code requests the baseline of currently existing threads with the threads request and then starts to listen for thread events to detect new or terminated threads. Even if your debug adapter does not support multiple threads, it must implement the threads request and return a single (dummy) thread. The id of this thread must be used in all requests where a thread id is required, e.g. stacktrace, pause, continue, next, stepIn, and stepOut."

So instead of sending a thread event, we'll have to find a way that you can reliably call a threads request.

It is just a time when this should be done. After the response from initializing request is recieved by vscode?

Though it feels cleaner to me that the adapter sends a thread event and we change the documentation. I understand this is a breaking change in a way but since this was never working in practice it will just be the change of docs.

@isidorn try to send the ThreadsRequest after the ConfigurationDoneRequest (or the legacy SetExceptionBreakpointsRequest).

Sending events for an old baseline state doesn't feel 'clean' because those events are basically sent out a second time (but at the first time no one was listening). The scenario is: start a server process and connect a debugger to it. The server will create new threads and sends thread events for them. Then restart the debugger. The new debugger should be able to pick up the already existing threads even if he missed the originals events.

In addition we had long discussions about thread events vs. threadRequest and came to the conclusion that thread events are optional and that debugAdapters don't have to send them. So I'm pretty sure that no existing debugAdapter sends out a threadEvent on connect.

To verify make sure you can pause a debug session even if it did not stop prior