Restarting a dynamic debug session with the same name as a regular configuration reads settings from launch.json

Andre Weinand (@weinand)

I've had reports that clicking the "Restart" button in the debug toolbar (when restart is handled by VS Code, and not the DA) starts the new session using values from launch.json even if the session was a dynamically created session.

I was able to repro this with a copy of MockDebug:

https://github.com/DanTup/vscode-repro-debug-restart
DanTup/vscode-repro-debug-restart@7ec8353

This adds a command called "MockDebug: Run without args" that starts a debug session dynamically:

vscode.debug.startDebugging(
	vscode.workspace.workspaceFolders![0],
	{
		name: "Mock",
		request: "launch",
		type: "mock",
		program: '${file}',
	},
);

There are no args in this launch config.

Opening the sample_project folder and putting a breakpoint in the .md file, then invoking the command causes the DA prints the args during launchRequest:

DA got args: undefined

If you hit the Restart button, it'll then print:

DA got args: from-launch.json

This is because it's started a new session using the launch config from launch.json, even though the launch.json was never involved in the session that was running.

This is undesirable - the launch.config should not be re-read. It seems like there is code to do this deliberately, but it's not clear why:

vscode/src/vs/workbench/contrib/debug/browser/debugService.ts

Line 657 in af9d0d5

    
           // Read the configuration again if a launch.json has been changed, if not just use the inmemory configuration

I guess this didn't consider dynamically-launched sessions and assumed they were always from launch.json (however honestly, I wouldn't expect it to re-read on a restart of a session from launch.config either.. I would expect a restart to be exactly as it was, since that's the only behaviour you could get from a DA-provided restart anyway).

Andre Weinand (@weinand) Isidor Nikolic (@isidorn) this may be slightly related to #21316.

I agree that this is an issue. Let me just verify something: this only happens if the dynamic configuration and a written configuration in launch.json have the same name?

this only happens if the dynamic configuration and a written configuration in launch.json have the same name?

In my real extension I don't have a name on the dynamic config (though it's possible if it goes through resolve, that it might be added on).

As a workaround I was considering making up a random name, but since that may show up in the UI (eg. the debug toolbar when the are multiple sessions), having a random name wouldn't be ideal.

TBH, even if I launched from launch.json and then modified it - I'm not sure I'd expect Restart to pick up the changes even in that case (especially as this would be inconsistent if the DA handles restart itself, as it definitely won't be reading new values from launch.json - it doesn't even know that's where they came from).

Danny Tuppeny (@DanTup)

Danny Tuppeny (@DanTup) if you do not set a name on your dynamic configuration then the call to getConfiguration here should return undefined and thus nothing should be read. Unleass you also have a configuration in launch.json which does not have a name.
Can you put a breakpoint at a pointer i provided and investigate more? Thanks

As for re-reading the config on restart - this was already discussed at lenght in a closed issue, you can search for it if you are interested in more details why we do this.

I checked, and it was as a I suggested above:

though it's possible if it goes through resolve, that it might be added on

When I launch the dynamic debug session, it goes through my resolve method, which populates some default values if they're not sent, including the name:

if (!debugConfig.name) {
	if (isFlutter && debugConfig.deviceId) {
		debugConfig.name = `Flutter (${debugConfig.deviceId})`;
	} else if (isFlutter && device) {
		debugConfig.name = `Flutter (${deviceManager ? deviceManager.labelForDevice(device) : device.name})`;
	} else if (isFlutter) {
		debugConfig.name = "Flutter";
	} else {
		debugConfig.name = "Dart";
	}
}

So this will pick up the name "Dart" here, which would then match what's in launch.json. We add the default name so if you run multiple sessions (for ex. a Dart backend, and a Flutter frontend) you can tell them apart easily in the debug UIs.

As for re-reading the config on restart - this was already discussed at lenght in a closed issue, you can search for it if you are interested in more details why we do this.

There are 294 results for "restart launch.json" - do you happen to remember anything that would help narrow it down? 😄

The only note I could find was this:

#47021 (comment)

The use case that triggered this was that a user edited a launch config and then aways restarted the debug session to pick up those changes.

However I still think this is questionable because if a DA handles restart itself it would not reload this config - so the behaviour will be inconsistent between DAs that do/don't handle their own restart. (Edit: Also found #19366 (comment) where it was originally fixed, but the only comment suggests it shouldn't be done, so it's not clear why it was decided to do it).

That aside, could dynamic sessions have some flag so they are excluded from the reload? I think forcing dynamic sessions to have some random name to avoid overlapping with launch.json is not ideal.

Ok, so the gist is: when there is a config with the same name in the launch.json it gets read. As a workaround I suggest you simply give a different name to the dynamic launch configuration. For example "Dart " with a space at the end.
We can look into fixing this issue on our end in the future when we introduce a distinction between dynamic configuraitons and regular ones - the distinciton which we currently do not have.

As for older discussions yeah that issue captures it quite well. Feel free to comment there.

As a workaround I suggest you simply give a different name to the dynamic launch configuration. For example "Dart " with a space at the end.

Yeah, that sounds better than being random, I'll do that in the meantime. Thanks!

Since there is a workaround for this I wil lclose this as out of scope.

We closed this issue because we don't plan to address it in the foreseeable future. You can find more detailed information about our decision-making process here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

Navigation Menu

Repository navigation

Restarting a dynamic debug session with the same name as a regular configuration reads settings from launch.json #100115

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Restarting a dynamic debug session with the same name as a regular configuration reads settings from launch.json #100115

Description

Activity

isidorn commented on Jun 15, 2020

DanTup commented on Jun 15, 2020

isidorn commented on Jun 15, 2020

DanTup commented on Jun 15, 2020

DanTup commented on Jun 15, 2020

DanTup commented on Jun 15, 2020

isidorn commented on Jun 15, 2020

DanTup commented on Jun 15, 2020

isidorn commented on Sep 8, 2020

vscode-triage-bot commented on Sep 8, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions