Vscode: Custom task providers no longer work in 1.31.0

[Gama11]

Version: 1.31.0-insider (system setup)
Commit: b313db6c58f8c02181a33cd3b5b4b17c64a5b85d
OS: Windows_NT x64 10.0.17134

---

The task returned by this simple example provider no longer shows up in the Run Task... UI for me with current Insider's builds:

Notably, a breakpoint in provideTasks still triggers when invoking the command, but for some reason the returned task seems to be discarded by VSCode?

It works with the current stable release (1.30.2), which would make this a regression:

---

'use strict';
import * as vscode from 'vscode';

export function activate(context: vscode.ExtensionContext) {
    vscode.workspace.registerTaskProvider("test", {
        provideTasks: () => {
            return [createTask("hello world")];
        },
        resolveTask(task: vscode.Task): vscode.Task | undefined {
            return task;
        }
    });
}

function createTask(message: string): vscode.Task {
    return new vscode.Task({type: "test"}, message, "test", new vscode.ShellExecution("echo " + message));
}

Relevant section from package.json:

"activationEvents": [
    "*"
],
"contributes": {
    "taskDefinitions": [
        {
            "type": "test"
        }
    ]
}

[vscodebot[bot]]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• TaskProvider: resolveTask() never gets called (#33523)
• Test dynamic extension points for Tasks, Problem Patterns, and Problem Matchers (#67285)
  

[Gama11]

It looks like this affects the 1.31.0 release as well. :(

[alexr00]

I'm still seeing gulp, npm, and tsc tasks get contributed. Trying out the provided example next.

[Gama11]

That's interesting - I wonder what they're doing differently than the taks providers of the Haxe, Lime and Kha extensions, which all seem affected by this.

[alexr00]

There are two constructors for Task. One takes a scope and the other (deprecated) does not. The issue is that Tasks is throwing out any task that doesn't include a scope. I'm still figuring out what changed to cause this since this was not intentional.

[alexr00]

Git bisect shows that this is the first commit with this isue: 51f7beb40c1faa3d911b751531d5a99a40cd376f.
I'm just testing the fix now.

[alexr00]

Fix: https://github.com/Microsoft/vscode/commit/6bbb04e0be4e77598b5075301d00d5089c21af9e

[Gama11]

Thanks!

We actually just pushed out a workaround for this, using the other constructor by specifying TaskScope.Workspace. Seems like that should be a pretty safe change considering the API has been around for a while, and it does work fine in 1.31.0. However, this seems to have broken tasks for users still running 1.30.

The symptoms seem to be identical to this original issue: breakpoint in provideTasks() triggers, but the task doesn't show up. In fact, none of the following seem to work in 1.30:

var execution = new vscode.ShellExecution("echo " + message);

return new vscode.Task({type: "test"}, vscode.TaskScope.Global, "test", "test", execution);
return new vscode.Task({type: "test"}, vscode.TaskScope.Workspace, "test", "test", execution);
return new vscode.Task({type: "test"}, vscode.workspace.workspaceFolders[0], "test", "test", execution);

Was this perhaps a known issue in 1.30.2?

[Gama11]

Hm, looks like this time around something is logged to the dev console:

mainThreadTask.ts:429 Dropping task test. Missing workspace folder and task definition

However, it's not obvious to me how the task definition or workspace folder is missing in these examples.

[Gama11]

I guess a runtime vscode version check may be needed on our end to decide which constructor to use, since one only seems to work in 1.30.0 and one only seems to work in 1.31.0.

Somewhat related, but maybe starting to get off-topic: we got a report from a user that Haxe tasks no longer seem to respect the environment variables that VSCode was started with. We do set ProcessExecutionOptions.env, but that is specified to be merged with the parent process environment. Have yet to look into it more deeply.

[alexr00]

I can't find any known issues where the constructor that takes a scope wouldn't work in old builds. I am surprised no one noticed that the constructor with a scope didn't work in that release. I'll try it out and see if there's a work around you can use besides the runtime check.

[Gama11]

No worries, the runtime check seems to work ok. :) I think we'll just increase the minimum VSCode version to 1.31.0 after that to avoid breaking old releases.

[Gama11]

The issue with environment variables I mentioned turned out to be a user error / not a problem with VSCode.