onDebugInitialConfigurations activation event causes extensions to load when pressing F5 to run other projects

[DanTup]

This has bugged me forever, but @isidorn informs me this isn't intended.

1. Clone mock-debug
2. Replace activationEvents with "onDebugInitialConfigurations"
   2.5 Change vscode engine version to 1.41 if using Stable (and delete InlineDebugAdapterFactory)
3. Run the project to launch extension dev host
4. Confirm mock-debug is not loaded
5. Open some project (for example Dart) that does not have a launch.json
6. Press F5
7. Note mock-debug is listed in the list and extension is activated

This behaviour is bad because many language extensions do expensive things at activation (downloaded SDK components, spawn language servers) which does not make sense to do for C#, Python, etc. when I'm pressing F5 to run my Dart (for ex.) project.

[DanTup]

Possibly related:

• onDebugInitialConfigurations activates very eager. #39696
• do not active debuggers when creating debug env drop down menu #37929
• Node Debug & Node Debug 2 unexpected activate when I press F5 in a non-node project vscode-node-debug#170

[weinand]

When VS Code needs the "Initial Configurations" for a to be created launch.json, it will have to activate all extensions that specify the "onDebugInitialConfigurations" filter.

So the next question is: in what situation does VS Code want to create a launch.json when F5 is pressed.

My understanding is that VS Code first tries to find a debugger registered for the language of the open editor. If there is no open editor or no debugger registered for the language, VS Code does not know what to do and it tries to create a launch.json by collecting all Initial Configurations from installed debugger extensions.

@DanTup are you seeing this problem even if you have a dart file open and the Dart debugger is registered for the Dart language?

[DanTup]

Sorry, I should've noted that - if a Dart file is open, it does use that. But if I just opened a project with no open files (or I have some other file, like pubspec.yaml open) then this occurs.

I understand why it happens, but if it's going to be normal that all language extensions are activated in this situation then VS Code should provide some guidelines on doing expensive work at activation. Currently most language extensions spawn language servers, and several download SDK components. Having all of this happen when you hit F5 in a project is a bad user experience. I've uninstalled several extensions like C# and reinstall only when working on a project because it was annoying to have them kicking off downloads all the time when starting Flutter apps.

[weinand]

• How bad is this problem?
  From my explanation above it has become clear that the problem only occurs once for a project, because a launch.json will be created and from then on there is no longer a need to activate all debuggers again on F5.
  If this is not the case, then it is a bug.

• Language extensions and debugger extensions:
  The VS Code architecture does not (yet) tie language extensions to debugger extensions in any way. However, certain extensions do this as an implementation detail. This makes their activation slow.
  The only way to address this issue is by avoiding long-running code (e.g. starting a language service) on activation. But this is difficult because a debugger extension might depend on a language extension which will be automatically activated first without knowing why it was activated (see your issue Provide activation reason to extensions in activate call #44711).
  The only thing we can do here is filing issues against the debugger extensions that have slow activation and help them address those issues (which might need to resolve Provide activation reason to extensions in activate call #44711 first...)

@isidorn any comments, insights from your side?

[DanTup]

From my explanation above it has become clear that the problem only occurs once for a project, because a launch.json will be created and from then on there is no longer a need to activate all debuggers again on F5.

It's not always the case that a launch.json is created. For most Dart/Flutter uses, I encourage to run without launch.json (and one is not created when pressing F5).

If the best fix is to have guidelines for extensions doing heavy work at activation, I think that's reasonable - but I do think there does need to at least be some guidance. There are lots of weird edge cases were extensions activate somewhat-unexpectedly (for ex #73656 and #75284) and right now there's nothing to suggest that extensions shouldn't spawn language servers or download SDK components at activation - they're generally written with the assumption that they are activated only when appropriate.

Providing an activation reason may help, but doesn't totally solve the issue. We could suppress spawning the language server (for ex.) if the activation reason was onDebugInitialConfigurations, but then it's not clear when we should spawn the language server if the user does go on to work on a project. We can't easily (for example) subscribe to an event that would trigger when the workspace contains a pubspec.yaml file in order to load the language server (which is functionality we get with activation).

[isidorn]

VS Code does not know what to do and it tries to create a launch.json by collecting all Initial Configurations from installed debugger extensions.

Correction here. VS Code will first ask the user what debugger to use. And then it is up to the debugger to decide. For example Node JS will try to launch and fail. C++ will return null in the resolveDebugConfiguration which will make vscode create a launch.json as we specified and only in this case will the onDebugInitialConfigurations be fired.

@DanTup I can not reproduce the issue following your steps. Mock debug only gets activated if a user has chosen a debugger after step 6. And only if that debugger chooses to create a launch.json. For example if the user chooses in step 6 nodeJS. MockDebug will not get activated.

[DanTup]

@isidorn not sure what we're doing differently, but I missed some steps if running on stable (have to change VS Code engine version and comment out some code that doesn't isn't valid for v1.41):

[isidorn]

Make sure that your changes to the mock debug got applied, since by default it activates onDebug which is a too general activation event.

[DanTup]

@isidorn at the start of the gif you can see my activation events, which is only this one. I can't find a way to confirm the activation event from within the dev host, but my understanding is that it's reading the extension directly from disk so it should read that manifest regardless of any build/etc.?

[isidorn]

Pushing this out since open since January and I will not have time to look into this next week.
Andre feel free to push back to April if you are passionate about this.

[DanTup]

If issues like this are not going to be fixed, it would really help if Code provided some guidelines about how language extensions should handle activation. Right now Dart spawns a language server unconditionally upon activation, because it seems silly to scan the whole workspace looking for Dart (when VS Code specifically gives up after 7 seconds and activates us anyway). However with VS code activation extensions with all sorts of events like this, we end up getting complaints from users that we're starting Dart language servers for unrelated projects. Seems like we have no good options.

[isidorn]

I was a bit too fast on the trigger here. Let's reopen as we might tackle in the future. Thanks

[DanTup]

This came up again today. A Flutter user clicked the "Create a launch.json" file on the run sidebar, and it appeared to do nothing at all. Turns out this may have triggered the C# extension to activate, and it start downloading SDK components.

It really would be nice to have some guidelines around expensive work in activation methods. C# is a first-party extension and it's causing VS Code's UI to be blocked for actions when users aren't even working in C# projects and it's not entirely clear to users that's what is happening.