Debug launching before preLaunchTask ready when dependsOn task defined

[halovanic]

• VSCode Version: 1.26.0-insider (and 1.25.1)
• Commit: 6babef9
• OS Version: Win10 x64

Does this issue occur when all extensions are disabled?: Yes

Steps to Reproduce:

1. Define a launch configuration with a preLaunchTask.
2. Define that preLaunchTask as a background task with a (non-background) dependsOn task to execute before it.
3. Debug with the launch configuration. The launch/debugger opens at what appears to be the completion of the dependsOn task, rather than when expected at the endsPattern of the preLaunchTask. It is not immediate, but it is far too early.

Taking out the dependsOn task from the preLaunchTask definition results in the expected behavior: the debugger waits to launch at the point that the preLaunchTask prints a message matching the endsPattern.

Also, making the preLaunchTask a non-background task seems to have the expected behavior: the dependsOn task executes before the preLaunchTask before the launch configuration.

There is no difficulty outside of the launch: the tasks defined execute in the expected sequence and match problems whether they were started directly, or via the launch. It's just that the debugger starts too early under these circumstances. It also does not seem to be specific to any one launch extension.

Thanks,
Alex

launch.json:

{
"version": "0.2.0",
"configurations": [
    {
        "type": "chrome",
        "request": "launch",
        "name": "Debug in Chrome",
        "url": "https://localhost:3801",
        "webRoot": "${workspaceFolder}",
        "preLaunchTask": "Build and Watch",
    }
]
}

tasks.json:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Install Packages",
            "type": "shell",
            "command": "yarn",
            "group": "build"
        },
        {
            "label": "Build and Watch",
            "dependsOn": "Install Packages",
            "type": "shell",
            "command": "yarn",
            "args": [
                "watch"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "problemMatcher": [
                {
                    "owner": "javascript",
                    "fileLocation": [
                        "relative",
                        "${workspaceFolder}"
                    ],
                    "pattern": [
                        {
                            "regexp": "(ERROR|WARNING) in (.*\\.js)",
                            "severity": 1,
                            "file": 2,
                        },
                        {
                            "regexp": "^.*$",
                        },
                        {
                            "regexp": "(.*)\\s\\((\\d+):(\\d+)\\)",
                            "message": 1,
                            "line": 2,
                            "column": 3
                        }
                    ],
                    "background": {
                        /* Problems are printed after this message. */
                        "beginsPattern": "Build Finished",
                        /* Matching Browsersync messaging. */
                        "endsPattern": "\\[TOOLKIT\\]",
                        "activeOnStart": true
                    }
                }
            ],
            "isBackground": true,
        }
    ]
}

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• isWatching task as preLaunchTask in launch.json (#6209)
• Allow preLaunchTask to just check running task (#50360)
• Run the default build task from launch configuration (#32239)

[halovanic]

I should also add that the only issue for me is just that the debugging browser launches before the website is ready: there is no actual problem with attaching or debugging, it just results in a "page could not be loaded" and having to manually refresh the browser.

If the preLaunchTask was already running prior to debug, then everything is fine too.

[isidorn]

The issue here is that the debugService is waiting for the Inactive task event here
If the task depends on some other task, I would expect Inactive is only fired once all the tasks have completed -> forwarding to @dbaeumer
Assign back to me if there is some other task API that I could use here which I am missing.

[dbaeumer]

No your assumption is correct.

[ejizba]

We're running into this as well for the functions extension. Here's our scenario: We provide a task func: host start and problem matcher func-watch which starts the Azure Functions host in the background. Users can attach to the host and debug with a launch.json like this:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Attach to Python Functions",
      "type": "python",
      "request": "attach",
      "port": 9091,
      "host": "localhost",
      "preLaunchTask": "func: host start"
    }
  ]
}

But a lot of times users will want to run a task before they start the functions host. For example, Python users might want to do pip install -r requirements.txt like this:

{
  "version": "2.0.0",
  "tasks": [
    {
      "type": "func",
      "command": "host start",
      "problemMatcher": "$func-watch",
      "dependsOn": "pipInstall"
    },
    {
      "label": "pipInstall",
      "type": "shell",
      "command": ". func_env/bin/activate && pip install -r requirements.txt"
    }
  ]
}

@dbaeumer Any updates on this issue? Or do you see any workarounds for us? Again - it's running all tasks as expected, but it's ignoring the func-watch problem matcher and attaches to the functions host before it's ready.

[dbaeumer]

I looked into this and it is actually something debug needs to fix. @isidorn and my assumption was incorrect. The thing here is that two tasks are started but debug reacts in task inactive event without checking if the task it started is signalling the inactive event. The event listener has an argument that event which has information about the task signalling the event

@isidorn The event has either a __task property for which I guess you can do an identity compare with the task to started. If you fetched the task before and kept it around for a while you might compare the id. This will stay the same even if the task instance has changed.

Moving back to debug. @isidorn sorry for putting you onto the wrong path here.

[isidorn]

@dbaeumer thanks a lot for the investigation and for the fix
@EricJizbaMSFT @halovanic please verify in tomorrows vscode insiders that this fix actually fixes your issue. I just verified it does not break existing behavior. Thanks!

[ejizba]

@isidorn I'm getting this every time I try to debug:

I created a simple VS Code extension that replicates the bug when you F5:
https://github.com/EricJizbaMSFT/helloworldext

VS Code version: Code - Insiders 1.30.0-insider (9e62a05, 2018-12-03T06:12:08.874Z)
OS version: Darwin x64 18.2.0

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz (8 x 2500)
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 video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled
Load (avg)	3, 3, 3
Memory (System)	16.00GB (4.71GB free)
Process Argv	.
Screen Reader	no
VM	0%

Extensions (7)

Extension	Author (truncated)	Version
tslint	eg2	1.0.40
vscode-cosmosdb	ms-	0.9.1
python	ms-	2018.11.0
azure-account	ms-	0.7.0
csharp	ms-	1.17.1
java	red	0.35.0
vscode-java-debug	vsc	0.15.0

[isidorn]

Thanks for the repro steps, reopening and I plan to investigate later today / tomorrow

[isidorn]

I can repro by cloning your repository.
So for this milestone I have decided to revert my "fix"

@dbaeumer @alexr00 the task ids that I am getting from the task service are not matching and so I can not detect that a task is started.

Assigning to @alexr00 and december to investigate than why the task ids are not matching.

To repro

1. Clone @EricJizbaMSFT repo
2. Set a breakpoint here and here
3. Start debugging and check the task ids I am getting are not matching the task.id

[dbaeumer]

@alexr00 I quickly looked into this and there is something wired here. In this setup the terminal doesn't give us any onExit callback hence we end up in a very wired state. We do get the callback correctly for a single watch task. So not critical for today.

[dbaeumer]

It does work if we give each task a dedicated panel

{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "npm",
            "script": "watch",
            "problemMatcher": "$tsc-watch",
            "isBackground": true,
            "presentation": {
                "reveal": "never",
                "panel": "dedicated"
            },
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "dependsOn": "npm: lint"
        },
        {
            "type": "npm",
            "script": "lint",
            "problemMatcher": "$tsc",
            "presentation": {
                "reveal": "never",
                "panel": "dedicated"
            },
        }
    ]
}

[dbaeumer]

And the IDs look stable to me. @isidorn I looked at your change and you still used a once listener. However if this starts n tasks like in the above example you need to listen until the one you started signals. The first one that signals in the above example is the npm lint task and that indeed has a different id :-)

[alexr00]

Based on @dbaeumer investigations, assigning back to @isidorn to listen for the right task.

[dbaeumer]

@alexr00 can you look into this: #54397 (comment) . The terminal doesn't give us the right events so this might still not work

[alexr00]

Looked into it, and not having the right events is a duplicate of #64226, which is in turn a duplicate of #57803. The initial tsc compile lines simply never make it to the terminal which means our watching problem matcher can't fire the events we need. Until #57803 is fixed there is no good work around. Once you see the tsc compile start you can save a source file to cause the missing lines to print to the terminal.

[ejizba]

@alexr00 I'm a little confused on if this is fixed or not. If it's not fixed - which issue should I track going forward?

[alexr00]

There are two issues that contribute to what you're seeing:

#64865 was causing the terminal to not sent an onExit event. This issue is now fixed.
#57803 is causing the first couple terminal lines from tsc to not show. This is caused by Windows and the only fix for it is to upgrade past build 1809. This is the issue to track going forward, though I don't believe there will be a fix for it.

[aeschli]

Steps to verify?

[alexr00]

On Windows:

1. Define a launch configuration with a preLaunchTask.

You can use the Launch VS Code configuration for this. Or a launch extension configuration if you want to test with an extension instead

2. Define that preLaunchTask as a background task with a (non-background) dependsOn task to execute before it.

Use the Build VS Code task or if you're testing with an extension use the npm run watch task as the preLaunchTask. Give it a dependsOn of a simple task that just echos something:

                {
			"label": "Simple Task",
			"type": "shell",
			"command": "echo test",
			"problemMatcher": [],
		}

3. Debug with the launch configuration. The launch/debugger opens at what appears to be the completion of the dependsOn task, rather than when expected at the endsPattern of the preLaunchTask. It is not immediate, but it is far too early.

Confirm that the Build VS Code task or the npm run watch task says that compilation was successful before launching.