VS Code 1.81.1 starts *all* onTaskType extensions when debugging

[larsch]

This issue is to ressurrect #175821 which was fixed, then closed, then reverted without comment.

The issue remains in 1.81.1. Attempting to run any task loads ALL extensions.

For example, for me it loads PlatformIO, Rust Analyzer, etc. when I'm working on a C project.

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.81.1
• OS Version: Linux

Steps to Reproduce:

1. See VS Code 1.76 starts *all* onTaskType extensions when debugging #175821

[Blokyk]

Any update on this? I'm still encountering this bug using 1.84.2, and it's very overwhelming to have every extension startup all at once (with their associated notifications) when you just want to debug your project :/

@ meganrogge since you were the one to revert the fix commit, could you at least explain why? Ok so it seems that the fix commit was reverted in #185812, and then that revert was reverted itself in #185925 because of the current issue; however, something must have broken, because despite the double-revert, the original issue (i.e. the current one) is still happening in 1.84.2

[hyangah]

I am a maintainer of the Go extension. We are observing that the Go extension is activated randomly due to this bug.
Is there any workaround extension authors can use until this issue is addresssed?

[blaine]

This is an extremely annoying bug. I have the rust-analyzer extension installed, and when I'm working on non-rust projects (e.g., a platformio C++ arduino project), rust-analyzer shows a very urgent red error message at the bottom of my screen. From all the related bugs, it sounds like this is a vscode issue, and extension authors are unable to fix it.

[carsonfarmer]

Seeing this issue as well from within a Swift project. I found this issue via: rust-lang/rust-analyzer#17018

[meganrogge]

I see the issue here. I don't think we ever should've adopted implicit activation for tasks - which means that onTaskType:x is added as an activation event for any extension that contributes a task x.

vscode/src/vs/workbench/contrib/tasks/common/taskDefinitionRegistry.ts

Lines 86 to 92 in 842e001

	activationEventsGenerator: (contributions: Configuration.ITaskDefinition[], result: { push(item: string): void }) => {
	for (const task of contributions) {
	if (task.type) {
	result.push(`onTaskType:${task.type}`);
	}
	}
	},

Thus, that extension will get activated when the build task command is run for example because in doing that, we call activate task providers, which fires the events for the whole registry.

vscode/src/vs/workbench/contrib/tasks/browser/abstractTaskService.ts

Lines 600 to 602 in 842e001

	for (const definition of TaskDefinitionRegistry.all()) {
	result.push(`onTaskType:${definition.taskType}`);
	}

We fire events for the whole registry for that case because tasks (including a build task) are provided in the extension programmatically and we want the execution of the task after user request to be expeditious vs waiting for on-demand extension activation.

vscode/src/vscode-dts/vscode.d.ts

Lines 8494 to 8505 in bfa1c61

	/**
	* A task provider allows to add tasks to the task service.
	* A task provider is registered via {@link tasks.registerTaskProvider}.
	*/
	export interface TaskProvider<T extends Task = Task> {
	/**
	* Provides tasks.
	* @param token A cancellation token.
	* @returns an array of tasks
	*/
	provideTasks(token: CancellationToken): ProviderResult<T[]>;

.

Reverting this should fix it:

#173192

[meganrogge]

This would also happen when debugging if the configured task for debugging lacks a type, which may be undefined

vscode/src/vs/workbench/contrib/tasks/browser/abstractTaskService.ts

Lines 792 to 795 in 4e9bc62

	// Nice, we found a configured task!
	const task = matchedTasks[0];
	if (ConfiguringTask.is(task)) {
	return this.tryResolveTask(task);

vscode/src/vs/workbench/contrib/tasks/browser/abstractTaskService.ts

Line 817 in 4e9bc62

await this._activateTaskProviders(configuringTask.type);

[meganrogge]

I have to revert this fix once again because we need to activate all task providing extensions when debugging as otherwise, a preLaunchTask might not be found. A user can set their preLaunchTask to be anything.

Similarly, build tasks can be set programmatically, using the TaskGroup API property. Thus, when the build task is run, we need to activate all extensions that contribute tasks.

In order to minimize the number of extension activations, we encourage people to set the type property for their preLaunchTask.

[isidorn]

This is unfortunate. Is there an alternative approach to fix this issue? Or is there some capability for tasks that we would have to add to tackle this?

[meganrogge]

One idea for the debugging case would be to add a task type property for preLaunchTask. #223081

[meganrogge]

I can repro when I set preLaunchTask to be ${defaultBuildTask}.

Currently, when ${defaultBuildTask} is used as a preLaunchTask we fetch all tasks, activating all providers, then filter to find the default build task. We then run it, which redundantly activates that provider.

The fix is to wait on activation. If we find a default build task, then its provider will be activated when it's run.

If we don't find one, then we'll fall back to the current behavior - activating all providers.

[connor4312]

I think that's good behavior. We might still be able to add some optimization for the case of extension-provided configurations. Maybe in workspace storage we keep a small LRU (say ~5 entries) to associate labels of tasks with the extensions that provide them, to avoid having to activate all extensions all the time if I run some npm: scriptThatIDontHaveATaskFor?

[isidorn]

Thanks @meganrogge for improving this. I just tried it out and it behaves better for me. Adding verified label
@larsch if you can still reproduce with the latest VS Code Insiders build do let us know. Thanks!