Mechanism to abort the debug launch without showing launch.json

[rodrigovaras]

We have today the with this method:
interface DebugConfigurationProvider {
resolveDebugConfiguration(...)

So far is flexible enough except in scenarios where we want our provider to abort the debug launch without having vscode to think that the configuration is wrong or missing something important. In the 'live share' scenario we are launching remote debug sessions by allowing vscode to display them but not necessary to launch a remote debug session that will eventually arrive later. We want the resolveDebugConfiguartion to allow this by return a blessed debug configuartion or probably best by throwing a DebugConfiguartionCancelledException() that vscode would handle nicely.

[rkeithhill]

Just ran into this today. After the PowerShell extension is activated, it takes about 5-8 seconds for the PowerShell Editor Services (lang/debug server) to finish starting up. While that is happening it isn't a good time to start debugging. ATM we have a NullReferenceException that occurs in PSES because it is still initializing. We could certainly fix the NullReferenceEx in PSES but I'm afraid this might be the tip of the iceberg in this case.

So I've put code in resolveDebugConfiguration to check the status of PSES and if it isn't in the Running state, we pop a warning notification and return out of the function. The notification asks the user to retry after PSES has finished starting but unfortunately, VSCode has switched the active editor to launch.json. This makes this approach annoying for the user as now they can't just press F5 again, they have to reselect the PowerShell editor window again and then press F5.

BTW if there's a better way to prevent debugging until the extension is ready, please let me know.

[weinand]

I've fixed this issue by adding the following line to the comment for resolveDebugConfiguration and implementing the behaviour on the VS Code side:

Returning the value 'null' prevents the debug session from starting and opens the underlying debug configuration instead.

With this it is now possible to control what happens when aborting resolveDebugConfiguration:

resolveDebugConfiguration(folder: WorkspaceFolder | undefined, config: DebugConfiguration, token?: CancellationToken): ProviderResult<DebugConfiguration> {

	return vscode.window.showErrorMessage(`Program missing in debug configuration`, { modal: true }, `Open 'launch.json'`).then(result => {
		if (result && result.indexOf('Open') >= 0) {
			return null;	// opens launch.json
		}
		return undefined;	// aborts debugging silently
	});
}

[testforstephen]

@weinand I like the new behavior, it works well for the workspace with launch.json file, but there may be a potential break change for the workspace without launch.json. It's better to keep the debugger owners for awareness.

In current VS Code 1.27.1, when the user clicks F5 in the workspace without launch.json file, VS Code will invoke resolveDebugConfiguration api first, if it's returned value is {}, or undefined, null, then delegate to provideDebugConfiguration api to generate launch.json file.

In the insider with your new change, the debugger extension must return null explicitly for resolveDebugConfiguration api, then VS Code will continue delegating to provideDebugConfiguration api to generate launch.json file. For all other return values, it will try to launch or abort debug session, no launch.json is generated or opened.

[weinand]

@testforstephen thanks for raising your concern.

@isidorn let's discuss. We might want to flip the "null" and "undefined".

[weinand]

We've concluded that the fix is good and @isidorn will make debug adapter authors aware of the change.

[isidorn]

@DanTup I know you are depending on this mechanism so please be aware of the change we are making in the new vscode release.
This comment covers the change #54213 (comment)
Basically now you should return null to explicitly let vscode know to open launch.json

[DanTup]

@isidorn Great, thanks! I can remove some crufty code with this (where we return a debug config that has a type = null). I'll make the changes and do some testing and shout if I hit any problems.

[DanTup]

Tested it and it works great for me, closes #51069 too. Thanks!

[isidorn]

@DanTup thanks for testing, adding verified label