Task type in task definition from execution is not the original type

[tal-sapan]

Bug Description:

When executing a task with a custom type (through a task provider, tasks.json or by creating a new Task instance and calling tasks.executeTask), the value of task.definition.type is different from the returned execution's execution.task.definition.type. For example, for a custom task that has a ShellExecution, the type becaomse shell. The original type is in the property taskType of the task.
This is different from the behavior in VSCode, where task.definition.type is the original type and taskType is not defined.
This makes it hard for extensions that listen to the task end event to determine the type of the task that ended. The difference is also not documented as far as I saw, so it could be a problem to rely on it, as it seems like a sort of internal property.
You can see the difference in behavior in an extension I created. It contributes a task definition, registers a task provider and contributes a command that creates the task and executes it, then shows an information message with both fields. It also listens to the task end event and shows the same message about the ended task.

This is how it looks in VSCode:

This is how it looks in Theia:

Relevant definitions in the package.json file:

"contributes": {
  "taskDefinitions": [
    {
      "type": "hello-task",
      "properties": {},
      "required": []
    }
  ],
  "commands": [
    {
      "command": "tasktype.RunHelloTask",
      "title": "Run my-hello task"
    }
  ]
}

The task provider:

function createTask(): vscode.Task {
  const taskDefinition = {
    type: HelloTaskProvider.taskType
  };
  return new vscode.Task(
    taskDefinition,
    vscode.workspace.workspaceFolders![0],
    "Hello User",
    "tasktype extension",
    new vscode.ShellExecution(`echo "Hello User!"`)
  );
}
class HelloTaskProvider implements vscode.TaskProvider {
  public static readonly taskType = "hello-task";
  provideTasks(token: vscode.CancellationToken): vscode.ProviderResult<vscode.Task[]> {
    const tasks: vscode.Task[] = [];
    tasks.push(createTask());
    return tasks;
  }
  resolveTask(task: vscode.Task, token: vscode.CancellationToken): vscode.ProviderResult<vscode.Task> {
    const genTask = createTask();
    genTask.definition = task.definition;
    return genTask;
  }
}

The command:

vscode.commands.registerCommand("tasktype.RunHelloTask", async () => {
  const execution = await vscode.tasks.executeTask(createTask());
  const taskDefinition = execution.task.definition;
  vscode.window.showInformationMessage(`Task executed. definition.type: ${taskDefinition.type}, definition.taskType: ${taskDefinition.taskType}`);
}, undefined);

The task end event listener:

vscode.tasks.onDidEndTask((e) => {
  const taskDefinition = e.execution.task.definition;
  vscode.window.showInformationMessage(`Task ended. definition.type: ${taskDefinition.type}, definition.taskType: ${taskDefinition.taskType}`);
}, undefined, context.subscriptions);

You can find the full implementation here: https://github.com/tal-sapan/tasktype

Steps to Reproduce:

1. Build the extension above using npm install && npm run package
2. Open Theia with this extension
3. From the command palette run the command Run my-hello task
4. The task opens a terminal and prints Hello User!. Then it shows the task and taskType properties returned from the task execution returned from executeTask and the onDidEndTask event. Expected behavior: the task property contains the original task type - hello-task, and the taskType property is undefined. Actual behavior: the type property contains the value shell and the taskType property contains the hello-task value.

Additional Information

• Operating System: Windows 10 (also tested on a Linux system)
• Theia Version: built from master (also tested on Theia 1.7.0 and 1.8.0)

[RomanNikitenko]

I faced with the similar problem related to task type #8756 (comment)

[danarad05]

@tal-sapan After testing it seems to me that #9377 fixes this issue. Could you confirm also (it is already merged into master)
Thanks

[tsmaeder]

I believe this one is fixed now. Closing.