Multiple calls to the same extension (DebugConfigurationProvider#resolveDebugConfiguration)

[alvsan09]

Bug Description:

While prototyping a solution for the support of dynamic debug configurations, it was observed that some extensions (e.g.
ms-vscode.js-debug) may have implemented side effects of configuration providers i.e. instantiating a terminal when calling resolveDebugConfiguration .

During testing of the above we can see that using this extension with theia would trigger the creation of multiple terminals instead of one.

Troubleshooting has shown that theia is calling this function multiple times to the same configuration provider and for the same configuration.

Steps to Reproduce: (v1.17.0)

The issue can be reproduced outside the prototype mentioned above with the help of a test fork of
the 'vscode-mock-debug` extension as described below.

1. Checkout the following vscode-mock-debug extension to your development environment e.g.

export theia=${HOME}/git/theia
cd $theia/plugins
gh repo clone alvsan09/vscode-mock-debug
cd vscode-mock-debug

checkout this specific branch:

git checkout theia-resolveDebugConfigurations

2. build the mock-extension

yarn
yarn compile
yarn run vscode:prepublish

3. start the theia application e.g.

cd $theia
yarn rebuild:browser
yarn start:browser

4. in chrome navigate to the mock sample workspace
   example: (replace with actual path to yours)
   http://localhost:3000/#/home/${USER}/git/theia/plugins/vscode-mock-debug/sampleWorkspace

5. Open the readme.md file

6. Switch to the Debug view and on the drop down menu select the option Add configuration... and select:

Mock: Debug Launch
the following configuration will be available:
"Mock - debug selected file in editor"

7. From the drop down menu select the new configuration above and press
   Start Debugging

8. Go back to your terminal (where you started theia) and see the multiple request arriving for the same configuration.
   

Additional Information

The location of the actual loop triggering the multiple calls is at the front end at:
the picture shows the content of this.contributors.
https://github.com/eclipse-theia/theia/blob/master/packages/plugin-ext/src/main/browser/debug/plugin-debug-service.ts#L114

Then a second loop is in place in the plugin host, this loop does not cause multiple calls as it filters the providers to be called as per the received debug type.
the picture shows the content of this.configurationProviders.
https://github.com/eclipse-theia/theia/blob/master/packages/plugin-ext/src/plugin/node/debug/debug.ts#L337

The purpose of the loop in the first link above is unclear and even the one in the second loop seems to provide a preference to a debug type of '*'. which is not clear either.

Some input on the history of this implementation would be very helpful !

• Operating System: Ubuntu
• Theia Version: v1.17.0

[tsmaeder]

The loop for '*' came in with #5645. Reading the debug API documentation, I don't think a debug type of '*' is valid, though. That we can activate a plugin on debug type '*' is a different issue.

[colin-grant-work]

That we can activate a plugin on debug type '*' is a different issue.

@tsmaeder, it sounds like what we should be doing here is ensuring activation of any plugin that activates on debug:* and then iterating through providers who have declared that they can provide the relevant type?

[alvsan09]

Looking at the code it seems that we are due for a refactoring on this area,
as the code base is mixing functionality of Configuration providers with Debugger contributions,

I think the Configuration providers should be available to the PluginDebugService,
so providing configurations as well as resolving configurations can be done by calling the providers of a given type (and the ones registering with '*').

The code base would not work properly as there may be plugins registering debugger contributors but not registering configuration providers as well as plugins registering configuration providers and not register debugger contributions.

We could hack a solution where we call any register contributor to resolve a configuration, but even that does not work for all cases (i.e. No debugger contributions registered and Configuration providers registered).

@tsmaeder, @colin-grant-work, Please let me know what you guys think!!

[colin-grant-work]

I was doing some checking in this area related to this issue and this PR, and I found a couple of new issues, as well. I think I've overstated the double registration issue: one is at read time when the manifest is processed and one is at activation time, but we're still ending up with redundancy. It definitely seems that some refactoring is due, and it sounds like you have a reasonable idea of where to begin, @alvsan09.