microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
163.05k stars 28.8k forks source link

VSCode is having issues when more than 1 shell type tasks have the same task as a dependency. #102885

Closed haugerbr closed 3 years ago

haugerbr commented 4 years ago

Issue Type: Bug

When we had two tasks that had the same dependent task, the task that is the dependency would run, and then one of the dependent tasks would take up the existing terminal and the other would spawn in a new terminal. However, now we have three tasks with the same task as a dependency. Now we are seeing two of the dependent tasks both try to run the task they have as their dependency, which causes issues because there can be only one instance of the task that is the dependency running at a time. The expected behavior to me is to have task that is the dependency run and then one of the dependent tasks would re-use that terminal while the other two spawn in new terminals.

VS Code version: Code 1.47.2 (17299e413d5590b14ab0340ea477cdd86ff13daf, 2020-07-15T18:22:06.216Z) OS version: Windows_NT x64 10.0.19041

System Info |Item|Value| |---|---| |CPUs|Intel(R) Xeon(R) W-2133 CPU @ 3.60GHz (12 x 3600)| |GPU Status|2d_canvas: enabled
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: disabled_off
protected_video_decode: unavailable_off
rasterization: enabled
skia_renderer: disabled_off_ok
video_decode: enabled
viz_display_compositor: enabled_on
viz_hit_test_surface_layer: disabled_off_ok
webgl: enabled
webgl2: enabled| |Load (avg)|undefined| |Memory (System)|31.66GB (12.30GB free)| |Screen Reader|no| |VM|0%|
Extensions (41) Extension|Author (truncated)|Version ---|---|--- Bookmarks|ale|11.3.1 project-manager|ale|11.1.0 npm-intellisense|chr|1.3.0 vscode-markdownlint|Dav|0.36.1 vscode-eslint|dba|2.1.8 vscode-dash|dee|2.4.0 gitlens|eam|10.2.2 tslint|eg2|1.0.44 vscode-npm-script|eg2|0.3.12 vscode-commands|fab|1.3.0 vscode-firefox-debug|fir|2.9.0 auto-run-command|gab|1.6.0 vscode-test-explorer|hbe|2.19.1 rest-client|hum|0.24.1 vscode-peacock|joh|3.7.2 chat|kar|0.35.0 vscode-azureappservice|ms-|0.17.0 vscode-azurefunctions|ms-|0.23.0 vscode-logicapps|ms-|0.2.42 vscode-dotnet-runtime|ms-|0.1.2 vscode-aks-tools|ms-|0.0.6 vscode-kubernetes-tools|ms-|1.2.1 azure-account|ms-|0.8.11 azurecli|ms-|0.5.0 github-issues-prs|ms-|0.9.2 powershell|ms-|2020.6.0 vsliveshare|ms-|1.0.2427 vsliveshare-audio|ms-|0.1.85 vsliveshare-pack|ms-|0.4.0 team|ms-|1.161.0 azurerm-vscode-tools|msa|0.11.0 debugger-for-chrome|msj|4.12.9 1es-oss-assistant|mso|0.2.0 vscode-yaml|red|0.9.1 code-settings-sync|Sha|3.4.3 markdown-preview-enhanced|shd|0.5.12 vscodeintellicode|Vis|1.2.9 vscode-icons|vsc|10.2.0 save-and-run|wk-|0.0.21 JavaScriptSnippets|xab|1.8.0 markdown-all-in-one|yzh|3.1.0 (1 theme extensions excluded)
alexr00 commented 4 years ago

Can you provide an example tasks.json that shows this issue?

haugerbr commented 4 years ago

@alexr00 sure. I should clarify this is happening when they run on the folder open action.

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Build XX",
            "type": "npm",
            "script": "vscodebuild",
            "problemMatcher": [
                "$msCompile"
            ],
            "group": "build"
        },
        {
            "label": "TS Watch",
            "type": "shell",
            "command": "${env:SYSTEMDRIVE}\\codets\\.bin\\tsc.cmd",
            "args": [
                "-w",
                "-p",
                "tsconfig.json"
            ],
            "isBackground": true,
            "presentation": {
                "reveal": "silent"
            },
            "problemMatcher": "$tsc-watch",
            "runOptions": {
                "runOn": "folderOpen"
            },
            "dependsOn": "Build XX"
        },
    {
            "label": "React TS Watch",
            "type": "shell",
            "command": "${env:SYSTEMDRIVE}\\codets\\.bin\\tsc.cmd",
            "args": [
                "-w",
                "-p",
                "Client/React/tsconfig.json"
            ],
            "isBackground": true,
            "presentation": {
                "reveal": "silent"
            },
            "problemMatcher": "$tsc-watch",
            "runOptions": {
                "runOn": "folderOpen"
            },
            "dependsOn": "Build XX"
        },
        {
            "label": "Container Service",
            "type": "npm",
            "script": "serve",
            "isBackground": true,
            "presentation": {
                "reveal": "silent"
            },
            "problemMatcher": [],
            "runOptions": {
                "runOn": "folderOpen"
            },
            "dependsOn": "Build XX"
        }
    ]
}
haugerbr commented 4 years ago

@alexr00 is the provided info sufficient?

alexr00 commented 4 years ago

Yes. I modeled similar set of tasks since the tasks you provided are project specific:

// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "My Task",
            "type": "shell",
            "command": "echo Hello",
            "problemMatcher": []
        },
        {
            "type": "npm",
            "script": "watch",
            "problemMatcher": "$tsc-watch",
            "isBackground": true,
            "presentation": {
                "reveal": "never"
            },
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "dependsOn": "My Task",
            "runOptions": {
                "runOn": "folderOpen"
            }
        },
        {
            "type": "typescript",
            "tsconfig": "tsconfig.json",
            "option": "watch",
            "problemMatcher": [
                "$tsc-watch"
            ],
            "group": "build",
            "label": "tsc: watch - tsconfig.json",
            "dependsOn": "My Task",
            "runOptions": {
                "runOn": "folderOpen"
            }
        },
        {
            "label": "shell Task",
            "command": "npm run watch",
            "type": "shell",
            "problemMatcher": [],
            "isBackground": true,
            "presentation": {
                "reveal": "never"
            },
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "dependsOn": "My Task",
            "runOptions": {
                "runOn": "folderOpen"
            }
        }
    ]
}

I used these tasks with the Hello World sample and the tasks work as expected: First "My Task" runs, then the three other tasks run, with one of the three other tasks re-using the original terminal. Can you try disabling your installed extensions and seeing if you still see the issue? Do you see the problem when you use my sample tasks?

haugerbr commented 4 years ago

@alexr00 it took me a while to figure it out but I was able to repro the issue using your task specification (slightly modified) without any extensions running. I added a sleep on the initial task so that you can see the initial task duplicated as I think the echo would have finished too quickly. It appears this issue happens when there is more than one shell type task sharing the same task as a dependency so I changed an additional task in your specification to the shell type in order to reproduce the issue.

// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "My Task",
            "type": "shell",
            "command": "sleep 15",
            "problemMatcher": []
        },
        {
            "type": "npm",
            "script": "watch",
            "problemMatcher": "$tsc-watch",
            "isBackground": true,
            "presentation": {
                "reveal": "never"
            },
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "dependsOn": "My Task",
            "runOptions": {
                "runOn": "folderOpen"
            }
        },
                {
            "label": "shell Task 1",
            "command": "echo HelloWorld",
            "type": "shell",
            "problemMatcher": [],
            "isBackground": true,
            "presentation": {
                "reveal": "never"
            },
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "dependsOn": "My Task",
            "runOptions": {
                "runOn": "folderOpen"
            }
        },
        {
            "label": "shell Task 2",
            "command": "npm run watch",
            "type": "shell",
            "problemMatcher": [],
            "isBackground": true,
            "presentation": {
                "reveal": "never"
            },
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "dependsOn": "My Task",
            "runOptions": {
                "runOn": "folderOpen"
            }
        }
    ]
}
alexr00 commented 4 years ago

Tasks I'm now testing with (the typescript compile tasks are tough to use since they re-write the terminal).

{
            "label": "My Task",
            "type": "shell",
            "command": "sleep 15",
            "problemMatcher": []
        },
        {
            "label": "shell Task 1",
            "command": "sleep 11",
            "type": "shell",
            "problemMatcher": [],
            "isBackground": true,
            "dependsOn": "My Task",
            "runOptions": {
                "runOn": "folderOpen"
            }
        },
        {
            "label": "shell Task 2",
            "command": "sleep 12",
            "type": "shell",
            "problemMatcher": [],
            "isBackground": true,
            "dependsOn": "My Task",
            "runOptions": {
                "runOn": "folderOpen"
            }
        },
        {
            "label": "shell Task 3",
            "command": "sleep 13",
            "type": "shell",
            "problemMatcher": [],
            "isBackground": true,
            "dependsOn": "My Task",
            "runOptions": {
                "runOn": "folderOpen"
            }
        }

The behavior I see is that sometimes "My Task" will run multiple time.

alexr00 commented 4 years ago

This is not easily fixed. You can do something like this as a workaround:

        {
            "label": "My Task",
            "type": "shell",
            "command": "sleep 15",
            "problemMatcher": []
        },
        {
            "label": "shell Task 1",
            "command": "sleep 11",
            "type": "shell",
            "problemMatcher": [],
            "isBackground": true,
        },
        {
            "label": "shell Task 2",
            "command": "sleep 12",
            "type": "shell",
            "problemMatcher": [],
            "isBackground": true,
        },
        {
            "label": "shell Task 3",
            "command": "sleep 13",
            "type": "shell",
            "problemMatcher": [],
            "isBackground": true,
        },
        {
            "label": "Other Tasks",
            "dependsOn": [
                "shell Task 1",
                "shell Task 2",
                "shell Task 3"
            ]
        },
        {
            "label": "Folder Tasks",
            "dependsOrder": "sequence",
            "dependsOn": [
                "My Task",
                "Other Tasks"
            ],
            "runOptions": {
                "runOn": "folderOpen"
            }
        }
haugerbr commented 4 years ago

Thanks! The workaround helps.

haugerbr commented 3 years ago

I can understand a feature being out of scope but how can bug that affects a valid use case be out of scope?

alexr00 commented 3 years ago

@haugerbr fair concern. It would perhaps have been more accurate for me to close as wont-fix instead, since the number of users affected (small), the complexity of a possible fix (high), the risk of a fix (high) are the reasons I closed it.