Compound launch configs with integrated terminals and nodemon no longer start reliably after 1.33.0

[markm77]

Issue Type: Bug

When starting compound launch config with members like shown below, some of the configs often (but not always) now fail with error of the type:

Cannot connect to runtime process, timeout after 10000 ms - (reason: Cannot connect to the target: connect ECONNREFUSED 127.0.0.1:26333).

This only started happening after upgrade to VS Code 1.33.0.

    {
        "type": "node",
        "request": "launch",
        "name": "XX",
        "runtimeExecutable": "nodemon",
        "cwd": "${workspaceFolder}/built/inst_workers",
        "program": "${workspaceFolder}/built/inst_workers/xx.js", 
        "restart": true,
        "env": {
            "NODE_ENV": "development",
            "FORCE_COLOR": "10"
        },
        //"outputCapture": "std",
        "console": "integratedTerminal",
        "internalConsoleOptions": "neverOpen"
    }

VS Code version: Code 1.33.0 (0dd516d, 2019-04-04T15:11:32.076Z)
OS version: Darwin x64 18.5.0

System Info

Item	Value
CPUs	Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz (12 x 2900)
GPU Status	2d_canvas: enabled checker_imaging: disabled_off flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: enabled rasterization: enabled surface_synchronization: enabled_on video_decode: enabled webgl: enabled webgl2: enabled
Load (avg)	3, 3, 1
Memory (System)	32.00GB (22.96GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions (9)

Extension	Author (truncated)	Version
swagger-viewer	Arj	2.2.1
vscode-eslint	dba	1.8.2
gitlens	eam	9.5.1
python	ms-	2019.3.6352
cpptools	ms-	0.22.1
ruby	reb	0.22.3
bash-debug	rog	0.3.4
vscode-lldb	vad	1.2.2
vscode-proto3	zxh	0.2.2

[markm77]

Unfortunately this is still present in 1.34.0. The interesting thing is - when launching configs one-by-one there is no issue. The issue only occurs when multiple configs are launched simultaneously via a compound config. Everything worked perfectly before 1.33 so this is very strange.... @weinand Is there any information I could provide to help resolve this?

[markm77]

Okay, after some investigations I have established that the issue doesn't occur if i set

"console": "externalTerminal"

It only occurs with "console": "integratedTerminal" where it would appear often some integrated terminals simply don't launch.

Over the next few days I will try to find time to run a simple experiment to see if this is a general problem with launching multiple integrated terminals simultaneously on macOS.... or whether it is specific to my configuration choices somehow (e.g. nodemon).

At least I now have a workaround with external terminals. 😀

[markm77]

After further investigation I've created a simple compound config to reproduce this issue. When running it often one or more of the configs fail. The behaviour is not deterministic but for me seems to occur at least half the time. I did find it necessary to use a runtimeExecutable (nodemon) to trigger the behaviour and am using three simple Node JS files (index1.js, index2.js, and index3.js) which consist of the single line setTimeout(() => {console.log('hi')}, 5000)

(As an aside, a weird thing I've also noticed is sometimes two processes seem to be put in the same integrated terminal with compound configs but generally each gets a separate terminal as expected for the compound config below.)

Please let me know if I can provide any further info in relation to this issue. Everything as far as I know is up-to-date, e.g. Nodemon version is 1.19.0, Node version is 12.1.0 etc

Compound config:

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "compounds": [
    {
      "name": "One + Two + Three",
      "configurations": [
        "One",
        "Two",
        "Three"
      ]
    },
  ],
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "One",
      "cwd": "${workspaceFolder}/One",
      "program": "${workspaceFolder}/One/index1.js",
      "runtimeExecutable": "nodemon",
      "runtimeArgs": [
        "--exitcrash",
      ],
      "restart": true,
      "console": "integratedTerminal",
    },
    {
      "type": "node",
      "request": "launch",
      "name": "Two",
      "cwd": "${workspaceFolder}/Two",
      "program": "${workspaceFolder}/Two/index2.js",
      "runtimeExecutable": "nodemon",
      "runtimeArgs": [
        "--exitcrash",
      ],
      "restart": true,
      "console": "integratedTerminal",
    },
    {
      "type": "node",
      "request": "launch",
      "name": "Three",
      "cwd": "${workspaceFolder}/Three",
      "program": "${workspaceFolder}/Three/index3.js",
      "runtimeExecutable": "nodemon",
      "runtimeArgs": [
        "--exitcrash",
      ],
      "restart": true,
      "console": "integratedTerminal",
    },
  ]
}

[markm77]

Unfortunately this issue is still present in 1.37 🙁

[markm77]

In case it helps anyone, a workaround I have begun using is to assign to each debug config a pre-launch task that delays the start of the config. As long as the configs each have a different delay they all now start fine.

Example pre-launch task:

    {
      "label": "Sleep: 1s",
      "type": "shell",
      "command": "sleep 1",
      "problemMatcher": [],
      "presentation": {
        "group": "tasks",
      },
    }

[Ghostbird]

This really annoying issue is still present in 1.48.2.

Is it really hard to reproduce, or does it only affect a small minority of the users?

Version: 1.48.2
Commit: a0479759d6e9ea56afa657e454193f72aef85bd0
Date: 2020-08-25T10:56:10.074Z
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Linux x64 4.19.0-10-amd64

My launch.json looks like this:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "A",
      "type": "coreclr",
      "request": "launch",
      "preLaunchTask": "build",
      "program": "${workspaceRoot}/A/bin/Debug/netcoreapp3.1/A.dll",
      "args": [],
      "cwd": "${workspaceRoot}/A",
      "linux": {
          "env": { "ASPNETCORE_ENVIRONMENT": "${env:USER}" },
      },
      "env": { "ASPNETCORE_ENVIRONMENT": "${env:USERNAME}" },
    },
    {
      "name": "B",
      "type": "coreclr",
      "request": "launch",
      "preLaunchTask": "build",
      "program": "${workspaceRoot}/B/bin/Debug/netcoreapp3.1/B.dll",
      "args": [],
      "cwd": "${workspaceRoot}/B",
      "linux": {
          "env": { "ASPNETCORE_ENVIRONMENT": "${env:USER}" },
      },
      "env": { "ASPNETCORE_ENVIRONMENT": "${env:USERNAME}" },
    },
  ],
  "compounds": [
    {
      "name": "A+B",
      "configurations": ["A", "B"]
    },
  ]
}

[Ghostbird]

Additionally, I have tested that this is independent of nodemon and integratedTerminal even without nodemon and with externalTerminal the behaviour is the same.

[Ghostbird]

I just found that this is caused by the presence of any preLaunchTask. If I remove those it works flawlessly, however I need my dotnet application to be built before launch.

I also tried the recommendation above with different sleep times. This does not affect the behaviour in any way. I tried the recommendation above exactly as given, and after some modification found out that this has nothing to do with sleep, and different times. The reason it works is that the OP distinctly named each preLaunchTask. I do that, it works because all tasks are launched separately and simultaneously, regardless of their actions. I tried both letting all tasks run sleep 1 and letting all tasks run an empty command. Both worked.

My hypothesis is that this is a bug in the preLaunchTask bundling of the compound launch mechanism. It seems that when multiple launches share a single preLaunchTask, it is only run once. However once it has run, it seems to have forgotten the original compound composition and launches only one (probably always the first) launch configuration of the compound.

The error does not occur when I move the preLaunchTask from the individual launch configurations to the compound preLaunchTask. However, this is not a valid situation, since I need to launch the individual configurations themselves as well regularly.

The error does occur when I copy the preLaunchTask used in the individual launch configurations to the compound preLaunchTask.