Review CustomExecution Lifecycle

[tsmaeder]

It is unclear what the lifecycle for CustomExecution objects related to tasks should be: there is no explicit disposal of these objects. We should ask for clarification from the VS Code team or inspect the VS Code source to find out and implement the necessary steps in Theia.

[tsmaeder]

VS Code seems to clean up some the executions of the tasks from executeTask, but not the executions from task providers. I assume that the reasoning is as follows:

• A custom execution can only be created through three code paths:
  • Contributed with a task
  • Contributed when resolving a task
  • Through an invocation of vscode.task.executeTask(task).
• Tasks are re-contributed and re-resolved before each time a task is executed from the UI
• Invocations of executeTask will be on-offs, the tasks in question do not live in the system beyond the invocation.

Tasks get a stable, computed id, so when re-contributing a task with the same id, the custom execution would get overwritten. This still feels like a memory-leak to me, since the set of contributed tasks can grow and shrink (and there seems to be no cleanup for that case).

The cleanup upon completion of a task from executeTask seems fine, but since we don't have stable id's, I would propose the following:

• Clean up the contributed executions when we start a "user interaction".

We have token that represents the scope of a user action in the task system (like invoking "Run Task..."). We know that this token will be renewed before the user starts a task related action. All tasks will be contributed again during such an action, all non-contributed tasks will be re-resolved before being executed. In this way, we'll hold on to the custom executions from the last time tasks were contributed, but this set is finite and will be cleaned up when we start the next task action.

@alvsan09 @vince-fugnitto @RomanNikitenko your do you think this is a valid approach?