I have also reproduced this without any extensions enabled

I also have the same issue which seems to have re-appeared with the last update. It seems to be linked to issue #63705 (and multiple others linked to it) which is closed atm. I tried adding "isBackground" to my sub-tasks but nothing seems to work. I currently bypass the problem by compiling outside of vscode. It might be the version tag that's at fault, but I recently switched to vscode and I'm not fully familiar.

 {
    "version": "2.0.0",
    "options": {
        "cwd": "${workspaceRoot}"
    },
    "tasks": [
        {
            "label": "cmake",
            "args": ["-DCMAKE_BUILD_TYPE=Debug"],
            "type": "shell",
            "command": "cmake",
            "isBackground": true
        },
        {
            "label": "make",
            "args": ["-j16"],
            "type": "shell",
            "command": "make",
            "isBackground": true
        },
        {
            "label": "Build",
            "dependsOn": ["cmake", "make"],
            "group":"build",
        }
    ]
}

</details>

@s73obrien thank you for the very simple example! I debugged it, and it looks like we are literally taking longer to run the tasks the second time, and because of that the debug system times out. For example, if you change your npm task to only ping 9 times instead of 12, it makes it before the debug system timeout. That's not a solution, it just illustrates what's going on.

Clearly the task system should try not to take noticeably longer to run tasks the second time; however, if you do have a long running task you could hit the debug system task timeout anyway. I'll look into what could be slowing things down so much the second time.

If you're going to have non-background tasks as your prelaunch task, they must take less than 10 seconds to run, otherwise you need to convert them into background tasks.

@isidorn FYI

Idealy we could also ask the user from debug land if after 10 seconds he wants to wait more..

@alexr00 Can you refer me to an issue that's more related to my problem? So that I don't file a new duplicate for the background task system not working and timing out my debug session each time I change my code? Now that you have changed the name of the issue, my comment became irrelevant...

Note: it's never timedout with my setup until the last update. With very evenly distributed build times between 1s to 5m.

@alexr00 For clarification:
Does the use of dependsOn force one's tasks to be run non-background? There seems to be precious little documentation about the expected behavior (unless I am missing it).
Or more to the point: why is it that, when run on its own, npm: task2 can seemingly run as long as it pleases?

@Feynstein have you tested to see if your tasks will run successfully once on a fresh instantiation of VSCode and then not-so-successfully thereafter, as described above? Your tasks.json looks identical to mine, topologically-speaking.

@s73obrien Oh yeah... I closed vscode, then clean build then reopenend and started debug and even though it was long, it did work! Then I changed a line, so there was basically only linking to do and it timed out! I'm in the right issue after all!

@s73obrien the debug system defines that a non-background task needs to finish in 10 seconds. As @isidorn said, ideally we'd ask the user after 10 seconds. You can have a background task that uses dependsOn (but the task in the depends on can't be background #70283), but to be a background task that can be used as a prelaunch task you must have a watching problem matcher.

@alexr00 But as I mentionned in my last comment, on a clean boot of vscode running my whole compilation (after a make clean) doesn't trigger any timeout. And then changing one line in one file (which is at least 10x faster) I get a timeout. Plus, it seems to have appeared with the latest update. This is unstable behaviour if I ever saw any.

Yes:

Clearly the task system should try not to take noticeably longer to run tasks the second time; however, if you do have a long running task you could hit the debug system task timeout anyway. I'll look into what could be slowing things down so much the second time.

A 10 second time limit seems severely too restrictive to me. Even on a small .NET Core project, dotnet build can take 10+ seconds if NuGet restore is slow. In almost any reasonable Node.js project I can't imagine npm install taking less than 10 seconds.

According to that rule, dotnet build should become a background task, but because of #70283 that makes Docker debugging impossible, because docker build has to depend on dotnet build.

I think we should rethink that 10 second timeout. Maybe 10 seconds without any output from the task, but even that is seriously restrictive.

EDIT: Per @alexr00's reply below, it's a 10 second limit to start, not 10 seconds to finish the task.

The 10 second timeout ended up being a red herring. There is a 10 second timeout, but is on the task starting not completing. Fix is pushed to master and will be available in the text insiders.

Ah, that makes sense. Ten seconds to start is reasonable.

The 10 second timeout ended up being a red herring. There is a 10 second timeout, but is on the task starting not completing. Fix is pushed to master and will be available in the text insiders.

Thanks Alex, is it going to be available in the Insiders nightly build today? Also, are there any plans to have a servicing release for the stable branch?

Yes, it is in the latest insiders now. It is also planned to be included in the 1.43.1 sable release.