Separate debug configuration providers from debug adapter contributors #10910

alvsan09 · 2022-03-22T19:15:12Z

What it does

The implementation of the vscode API for the resolution of initial
debug configurations as well as the resolution of specific
configurations was relying on registered debug adapter
contributors rather than debug configuration providers,
this is causing issues e.g. #9978.

This implementation brings access to the debug configuration
providers all the way to the browser debug/plugin-debug-service,
where the providers can be filtered and then call its corresponding
API indirectly towards the extension host.

The former API is kept and marked deprecated.

How to test

Based on: #5645
Use the test extension in the tar file as follows:
https://github.com/alvsan09/debug-activation-events/raw/master/plugins.tar

NOTE: It is recommended to install only the required test extension(s), otherwise not all notifications may appear (must likely due to a hard coded limit).

test onDebug: install on-debug-0.0.1.vsix and check that onDebug notification appears on any debug activation event
test onDebugInitialConfigurations:
- install on-debug-initial-configurations-0.0.1.vsix
- delete launch.json file
- try to add a new configuration with markdown file opened
- you should see onDebugInitialConfigurations and provideDebugConfigurations notifications plus mock debug configuration should be generated dynamically
test onDebugResolve:
- install on-debug-resolve-0.0.1.vsix
- try to run any launch configuration
- you should see onDebugResolve and resolveDebugConfiguration(*)[0] notifications
test onDebugResolve:<debug type>:
- install on-debug-resolve-node-0.0.1.vsix
- try to run any node launch configuration
- you should see onDebugResolve:node and resolveDebugConfiguration:node notifications
test calling two different extension providers for debug type '*' supporting onDebugResolve :
- install on-debug-resolve-0.0.1.vsix
- install on-debug-resolve-2.vsix
- try to run any node launch configuration
- you should see resolveDebugConfiguration(*)[0] and resolveDebugConfiguration(*)[1] notifications, one for each of the installed on-debug-resolve-* extensions.
test Multiple calls to the same extension (DebugConfigurationProvider#resolveDebugConfiguration) #9978, follow the instructions on the issue:
- you should now see two terminals created one for the session and the other one triggered by the extension (there is still an issue here as the behavior does not match vscode (i.e. vscode does not mantain a session), however the original issue is resolved as we no longer create additional terminals i.e. one per registered debug adapter contributor).

Review checklist

As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

As a reviewer, I agree to behave in accordance with the review guidelines

colin-grant-work

Regarding the testing steps, all worked for me.

onDebug appears for any event.
onDebugInitialConfigurations appears when no launch.json + add config + markdown open.
onDebugResolve appears when running any configuration.
onDebugResolve:node appears when running a node configuration.
both onDebugResolve:* activation plugins are called.
multiple calls are not made to each provider for each resolution.

Regarding the code, it looks good for the most part. I had some comments about the location of some interfaces and a change to the DebugService interface, and some questions about some of the implementation details that mostly come from the old code.

packages/plugin-ext/src/main/browser/debug/plugin-debug-service.ts

colin-grant-work · 2022-03-22T22:44:31Z

packages/plugin-ext/src/main/browser/debug/plugin-debug-service.ts

+        if (pluginProviders.length === 0) {
            return this.delegated.provideDebugConfigurations(debugType, workspaceFolderUri);
        }
-    }
-
-    async provideDynamicDebugConfigurations(): Promise<{ type: string, configurations: DebugConfiguration[] }[]> {
-        const result: Promise<{ type: string, configurations: theia.DebugConfiguration[] }>[] = [];

-        for (const [type, contributor] of this.contributors.entries()) {
-            const typeConfigurations = this.resolveDynamicConfigurationsForType(type, contributor);
-            result.push(typeConfigurations);
+        let results: DebugConfiguration[] = [];
+        for (const provider of pluginProviders) {
+            const result = await provider.provideDebugConfigurations(workspaceFolderUri);
+            if (result) {
+                results = results.concat(result);
+            }
        }

-        return Promise.all(result);
+        return results;


This is another place where I'm not sure I understand what's going on. Since we may return this.delegated.provideDebugConfigurations, we believe that it's possible that the non-plugin debug system may have information that the plugin system doesn't, but we only use it if the plugin system definitely knows nothing about the relevant type. Shouldn't we use what the non-plugin system knows even if the plugin system also has some information about the type in question? Put another way, why do we give precedence to plugins and exclude Theia extensions in this case?

That's a very good question Colin !
I have just kept the logic that existed before this change,
as the non-plugin and plugin contributions have been so far separated by an else statement, this logic exists from the first version of this file.

It is a very good topic for discussion, although it seems out of the scope of this change. Do you agree?

colin-grant-work · 2022-03-22T22:51:30Z

packages/debug/src/browser/debug-prefix-configuration.ts

+        const map = await this.debugConfigurationManager.provideDynamicDebugConfigurations();
+        for (const [type, dynamicConfigurations] of map) {


This looks like the only place that this method is used, so I'm not sure about the need for the change from {type: string, configurations: DebugConfiguration[]} to Map<string, DebugConfiguration[]>. Apart from the breaking change, I wouldn't mind, but since the base DebugService lives on the backend and is called from the frontend, the return types of its interface should be easily serializable types, and Maps don't implement a toJSON method, so they can't easily be transmitted between the backend and the frontend.

The return type in the base was confusing i.e. "
{ type: string, configurations: DebugConfiguration[] }[]"

it indicates the possibility to have more than one object for the same 'type'.

In the other hand, the consolidated list from all the providers does not actually cross the 'json-rpc' interface, this is resolved in browser code under the 'debug-plugin-service.ts' see:

https://github.com/eclipse-theia/theia/blob/asl/multiple_calls_same_config_provider/packages/plugin-ext/src/main/browser/debug/plugin-debug-service.ts#L134

This method will be used once more under the open PR providing support for dynamic configurations on the debug view, so I think it's good to rectify the meaning before its use propagates further.

Let me know what you think !

It's true that the existing type doesn't ensure that all DebugConfigurations for a given heading are actually grouped together, and it's true that the only actual implementation of the method currently lives in the browser, but I'd still prefer to avoid adding a type to the interface that absolutely couldn't be implemented by the base DebugService on the backend. Given that, Record<string, DebugConfiguration[] | undefined> would achieve the goal of grouping configurations while retaining serializibility.

colin-grant-work · 2022-03-22T22:58:01Z

packages/debug/src/common/debug-service.ts

+export interface DebugConfigurationProvider {
+    readonly handle: number;
+    readonly type: string;
+    readonly triggerKind: DebugConfigurationProviderTriggerKind;
+    provideDebugConfigurations?(folder: string | undefined): Promise<DebugConfiguration[]>;
+    resolveDebugConfiguration?(folder: string | undefined, debugConfiguration: DebugConfiguration): Promise<DebugConfiguration | undefined>;
+    resolveDebugConfigurationWithSubstitutedVariables?(folder: string | undefined, debugConfiguration: DebugConfiguration): Promise<DebugConfiguration | undefined>;
+}
+
+export interface DebugConfigurationProviderDescriptor {
+    readonly handle: number,
+    readonly type: string,
+    readonly trigger: DebugConfigurationProviderTriggerKind,
+    readonly provideDebugConfiguration: boolean,
+    readonly resolveDebugConfigurations: boolean,
+    readonly resolveDebugConfigurationWithSubstitutedVariables: boolean
+}


Both of these interfaces are only used in the plugin-ext package. Are they relevant to the 'internal' debugging system?

Good point!,
I have moved them under the plugin-api-rpc.ts file as it already contained a definition for 'DebugConfigurationProviderTriggerKind' and keeps then under the same plugin-ext package.

packages/plugin-ext/src/main/browser/debug/debug-main.ts

colin-grant-work · 2022-03-22T23:04:57Z

packages/plugin-ext/src/main/browser/debug/plugin-debug-service.ts

+        for (const provider of pluginProviders) {
+            const result = await provider.provideDebugConfigurations(workspaceFolderUri);
+            if (result) {
+                results = results.concat(result);


Minor: I think results.push(...result) would be a little better than creating a new array each time.

Makes sense !! Done!

colin-grant-work · 2022-03-22T23:05:47Z

packages/plugin-ext/src/main/browser/debug/plugin-debug-service.ts

-        return { type, configurations };
+        const configurationsMap = new Map<string, DebugConfiguration[]>();
+
+        await Promise.all(Array.from(pluginProviders, async provider => {


Minor:

Suggested change

await Promise.all(Array.from(pluginProviders, async provider => {

await Promise.all(pluginProviders.map(async provider => {

Done, thanks !

colin-grant-work · 2022-03-22T23:10:44Z

packages/plugin-ext/src/plugin/node/debug/debug.ts

+        const results = this.configurationProviders.filter(p => p.handle === handle);
+        if (results.length === 0) {
+            throw new Error('No Debug configuration provider found with given handle number: ' + handle);
+        }
+        const { provider, type } = results[0];


Minor:

Suggested change

const results = this.configurationProviders.filter(p => p.handle === handle);

if (results.length === 0) {

throw new Error('No Debug configuration provider found with given handle number: ' + handle);

}

const { provider, type } = results[0];

const record = this.configurationProviders.find(p => p.handle === handle);

if (!record) {

throw new Error('No Debug configuration provider found with given handle number: ' + handle);

}

const { provider, type } = record;

Done, thanks !

alvsan09

Addressing review comments, and reflected the updates in the latest commit!

alvsan09 · 2022-03-23T12:59:21Z

packages/debug/src/browser/debug-prefix-configuration.ts

+        const map = await this.debugConfigurationManager.provideDynamicDebugConfigurations();
+        for (const [type, dynamicConfigurations] of map) {


The return type in the base was confusing i.e. "
{ type: string, configurations: DebugConfiguration[] }[]"

it indicates the possibility to have more than one object for the same 'type'.

In the other hand, the consolidated list from all the providers does not actually cross the 'json-rpc' interface, this is resolved in browser code under the 'debug-plugin-service.ts' see:

https://github.com/eclipse-theia/theia/blob/asl/multiple_calls_same_config_provider/packages/plugin-ext/src/main/browser/debug/plugin-debug-service.ts#L134

This method will be used once more under the open PR providing support for dynamic configurations on the debug view, so I think it's good to rectify the meaning before its use propagates further.

Let me know what you think !

alvsan09 · 2022-03-23T17:29:35Z

packages/debug/src/common/debug-service.ts

+export interface DebugConfigurationProvider {
+    readonly handle: number;
+    readonly type: string;
+    readonly triggerKind: DebugConfigurationProviderTriggerKind;
+    provideDebugConfigurations?(folder: string | undefined): Promise<DebugConfiguration[]>;
+    resolveDebugConfiguration?(folder: string | undefined, debugConfiguration: DebugConfiguration): Promise<DebugConfiguration | undefined>;
+    resolveDebugConfigurationWithSubstitutedVariables?(folder: string | undefined, debugConfiguration: DebugConfiguration): Promise<DebugConfiguration | undefined>;
+}
+
+export interface DebugConfigurationProviderDescriptor {
+    readonly handle: number,
+    readonly type: string,
+    readonly trigger: DebugConfigurationProviderTriggerKind,
+    readonly provideDebugConfiguration: boolean,
+    readonly resolveDebugConfigurations: boolean,
+    readonly resolveDebugConfigurationWithSubstitutedVariables: boolean
+}


Good point!,
I have moved them under the plugin-api-rpc.ts file as it already contained a definition for 'DebugConfigurationProviderTriggerKind' and keeps then under the same plugin-ext package.

packages/plugin-ext/src/main/browser/debug/debug-main.ts

alvsan09 · 2022-03-23T18:57:46Z

packages/plugin-ext/src/main/browser/debug/plugin-debug-service.ts

+        for (const provider of pluginProviders) {
+            const result = await provider.provideDebugConfigurations(workspaceFolderUri);
+            if (result) {
+                results = results.concat(result);


Makes sense !! Done!

alvsan09 · 2022-03-23T19:16:35Z

packages/plugin-ext/src/main/browser/debug/plugin-debug-service.ts

+        if (pluginProviders.length === 0) {
            return this.delegated.provideDebugConfigurations(debugType, workspaceFolderUri);
        }
-    }
-
-    async provideDynamicDebugConfigurations(): Promise<{ type: string, configurations: DebugConfiguration[] }[]> {
-        const result: Promise<{ type: string, configurations: theia.DebugConfiguration[] }>[] = [];

-        for (const [type, contributor] of this.contributors.entries()) {
-            const typeConfigurations = this.resolveDynamicConfigurationsForType(type, contributor);
-            result.push(typeConfigurations);
+        let results: DebugConfiguration[] = [];
+        for (const provider of pluginProviders) {
+            const result = await provider.provideDebugConfigurations(workspaceFolderUri);
+            if (result) {
+                results = results.concat(result);
+            }
        }

-        return Promise.all(result);
+        return results;


That's a very good question Colin !
I have just kept the logic that existed before this change,
as the non-plugin and plugin contributions have been so far separated by an else statement, this logic exists from the first version of this file.

It is a very good topic for discussion, although it seems out of the scope of this change. Do you agree?

alvsan09 · 2022-03-23T19:22:03Z

packages/plugin-ext/src/main/browser/debug/plugin-debug-service.ts

-        return { type, configurations };
+        const configurationsMap = new Map<string, DebugConfiguration[]>();
+
+        await Promise.all(Array.from(pluginProviders, async provider => {


Done, thanks !

packages/plugin-ext/src/main/browser/debug/plugin-debug-service.ts

alvsan09 · 2022-03-23T21:25:48Z

packages/plugin-ext/src/plugin/node/debug/debug.ts

+        const results = this.configurationProviders.filter(p => p.handle === handle);
+        if (results.length === 0) {
+            throw new Error('No Debug configuration provider found with given handle number: ' + handle);
+        }
+        const { provider, type } = results[0];


Done, thanks !

alvsan09 · 2022-03-23T22:28:47Z

Hi @colin-grant-work ,
I have addressed your comments and encapsulated my answers in a review to avoid sending individual notifications,
I hope this is not confusing!
Thanks !

alvsan09 · 2022-03-24T16:40:02Z

This PR has just been re-based to the latest master

paul-marechal

Just did a high level pass.

packages/plugin-ext/src/main/browser/debug/plugin-debug-service.ts

alvsan09 · 2022-03-24T18:24:21Z

Just did a high level pass.

Updated in the latest commit!! Thanks !!

packages/plugin-ext/src/plugin/node/debug/debug.ts

alvsan09 · 2022-03-24T19:34:20Z

@paul-marechal ,
The formatting remarks have been addressed in the latest commit !
Thanks !

colin-grant-work

All of the provided plugins work as expected. @paul-marechal, if you'd give it another pass, I'd appreciate it - it LGTM.

paul-marechal

Just a few remarks, but the logic looks good.

packages/plugin-ext/src/main/browser/debug/plugin-debug-service.ts

packages/plugin-ext/src/plugin/node/debug/debug.ts

packages/plugin-ext/src/main/browser/debug/plugin-debug-configuration-provider.ts

packages/plugin-ext/src/main/browser/debug/plugin-debug-service.ts

alvsan09 · 2022-03-29T13:09:40Z

Just a few remarks, but the logic looks good.

I have addressed all your comments except for the optional one which is an alternative I considered but I preferred the current one.
Thanks @paul-marechal !!

paul-marechal

Code LGTM

The implementation of the vscode API for the resolution of initial debug configurations as well as the resolution of specific configurations was relying on the registered debug adapter contributors rather than debug configuration providers, this is causing issues e.g. #9978. This implementation brings access to the debug configuration providers all the way to the browser debug/plugin-debug-service, where the providers can be filtered and then call its corresponding API indirectly. The former API is kept as deprecated. Signed-off-by: Alvaro Sanchez-Leon <[email protected]>

alvsan09 requested review from colin-grant-work, vince-fugnitto and paul-marechal March 22, 2022 20:24

colin-grant-work reviewed Mar 22, 2022

View reviewed changes

alvsan09 commented Mar 23, 2022

View reviewed changes

alvsan09 force-pushed the asl/multiple_calls_same_config_provider branch from 8dca7bb to 986e792 Compare March 24, 2022 16:10

vince-fugnitto added the debug issues that related to debug functionality label Mar 24, 2022

alvsan09 force-pushed the asl/multiple_calls_same_config_provider branch from 986e792 to c001e24 Compare March 24, 2022 16:34

paul-marechal reviewed Mar 24, 2022

View reviewed changes

packages/plugin-ext/src/plugin/node/debug/debug.ts Outdated Show resolved Hide resolved

packages/plugin-ext/src/plugin/node/debug/debug.ts Outdated Show resolved Hide resolved

colin-grant-work self-requested a review March 25, 2022 22:00

colin-grant-work approved these changes Mar 28, 2022

View reviewed changes

paul-marechal reviewed Mar 29, 2022

View reviewed changes

paul-marechal approved these changes Mar 30, 2022

View reviewed changes

alvsan09 force-pushed the asl/multiple_calls_same_config_provider branch from 04193c2 to 8997745 Compare March 30, 2022 18:01

alvsan09 merged commit 580fd11 into master Mar 30, 2022

alvsan09 deleted the asl/multiple_calls_same_config_provider branch March 30, 2022 18:21

github-actions bot added this to the 1.24.0 milestone Mar 30, 2022

colin-grant-work mentioned this pull request Apr 20, 2022

Redundant double debug registrations for plugins #10835

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Separate debug configuration providers from debug adapter contributors #10910

Separate debug configuration providers from debug adapter contributors #10910

alvsan09 commented Mar 22, 2022 •

edited

Loading

colin-grant-work left a comment •

edited

Loading

colin-grant-work Mar 22, 2022

alvsan09 Mar 23, 2022

colin-grant-work Mar 22, 2022

alvsan09 Mar 23, 2022

colin-grant-work Mar 23, 2022

colin-grant-work Mar 22, 2022

alvsan09 Mar 23, 2022

colin-grant-work Mar 22, 2022

alvsan09 Mar 23, 2022

colin-grant-work Mar 22, 2022

alvsan09 Mar 23, 2022

colin-grant-work Mar 22, 2022

alvsan09 Mar 23, 2022

alvsan09 left a comment •

edited

Loading

alvsan09 Mar 23, 2022

alvsan09 Mar 23, 2022

alvsan09 Mar 23, 2022

alvsan09 Mar 23, 2022

alvsan09 Mar 23, 2022

alvsan09 Mar 23, 2022

alvsan09 commented Mar 23, 2022

alvsan09 commented Mar 24, 2022

paul-marechal left a comment

alvsan09 commented Mar 24, 2022 •

edited by paul-marechal

Loading

alvsan09 commented Mar 24, 2022

colin-grant-work left a comment

paul-marechal left a comment

alvsan09 commented Mar 29, 2022 •

edited by paul-marechal

Loading

paul-marechal left a comment

		const map = await this.debugConfigurationManager.provideDynamicDebugConfigurations();
		for (const [type, dynamicConfigurations] of map) {

	await Promise.all(Array.from(pluginProviders, async provider => {
	await Promise.all(pluginProviders.map(async provider => {

Separate debug configuration providers from debug adapter contributors #10910

Separate debug configuration providers from debug adapter contributors #10910

Conversation

alvsan09 commented Mar 22, 2022 • edited Loading

What it does

How to test

Review checklist

Reminder for reviewers

colin-grant-work left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alvsan09 left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alvsan09 commented Mar 23, 2022

alvsan09 commented Mar 24, 2022

paul-marechal left a comment

Choose a reason for hiding this comment

alvsan09 commented Mar 24, 2022 • edited by paul-marechal Loading

alvsan09 commented Mar 24, 2022

colin-grant-work left a comment

Choose a reason for hiding this comment

paul-marechal left a comment

Choose a reason for hiding this comment

alvsan09 commented Mar 29, 2022 • edited by paul-marechal Loading

paul-marechal left a comment

Choose a reason for hiding this comment

alvsan09 commented Mar 22, 2022 •

edited

Loading

colin-grant-work left a comment •

edited

Loading

alvsan09 left a comment •

edited

Loading

alvsan09 commented Mar 24, 2022 •

edited by paul-marechal

Loading

alvsan09 commented Mar 29, 2022 •

edited by paul-marechal

Loading