Well the stop sent a disconnect request to the debug extension. HOwever the debug extension ignored it and still started.
So the debug extensions should get a disconnect request. It can respect it and stop starting.

@ivanhernandez13 are you an extension writer. Do you see some idfferent behavior than what I just mentioned?

And sorry for the slow reponse, I was on vacation.

No worries, thanks for the response. I am working on a debug extension that uses an executable for the debug adapter.

The series of events you describe are accurate but only occur after the debug adapter has started and that only occurs after resolveDebugConfiguration() has completed. The order of events I am seeing is:

1. Click on 'Start Debugging'
2. resolveDebugConfiguration() is called and performs its duties.
3. resolveDebugConfiguration() completes and returns a complete debug configuration.
4. createDebugAdapterDescriptor() is called and returns a vscode.DebugAdapterExecutable or vscode.DebugAdapterServer.
5. Debug adapter executable is spawned or connected to.
6. Debug adapter receives initialize request. (Can also receive disconnect requests)

So if the user happens to click stop between steps 2-5, there is no way to detect a disconnect request (that I can see). In the example and video I provided, I happen to click on stop while in step 2 so the disconnect request can't be caught yet because the adapter hasn't been spawned. Or am I missing something and there is a way in the extension itself to detect that stop was clicked on?

I mentioned I tried the cancellation token's onCancellationRequested() and vscode.debug.onDidTerminateDebugSession() events but neither were called.

Ok, thanks for providing more details.
Yes you are right it can happen that the disconnect comes before the initialize.

In order to reproduce this situation I have changed the initialize to be sent with a timeout.
That way I would get into a situation that the disconnect happens first. And I could still see the vscode.debug.onDidTerminateDebugSession() being fired.
So that event should always get fired, even if the session is not fully initialised when it is shutdown by the user.

If you would like me to investigate more, please create a fork of mock-debug with the changes such that I can just clone it and reproduce the issue on my machine such that the onDidTerminateDebugSession is not fired.
Thanks!

https://github.com/ivanhernandez13/vscode-mock-debug.git

This will wait 5 seconds before resolving the debug configuration in resolveDebugConfiguration(). It will also present a message when the debug session is terminated. If you hit stop before those 5 seconds nothing will happen.

@ivanhernandez13 Great steps. I can now reproduce the issue nicely and I acknowledge what you were saying: that the debug adapter is not yet spawned, thus it is not possible to send a disconnect.
The only way to fix this is to propagate the cancelation token form our API down to our internal debug logic.
@weinand assigning to you to look into propagating the cancelation token down, and then I can wire it in.

@isidorn the two ConfigurationManager methods resolveConfigurationByProviders and
provideDebugConfigurations now have an optional CancellationToken argument.

@weinand thanks.
I have wired the cancelation token in and it seems to work nicely.
@ivanhernandez13 I have tried with your sample and it looks good. You can also verify once we release new insiders in a couple of days.
Basicaly now when the user stops the initialisaition of the debug session the cancelation token will get cancled.

I built VS Code from head to try this out and works great, thanks!

@ivanhernandez13 thanks for letting us know!