Vscode: First F5 fails without a problem matcher in tasks.json

[EricJizbaMSFT]

• VSCode Version: Code - Insiders 1.17.0-insider (f7962f0682a76516df51de4856f8ccc5d8ad578a, 2017-09-20T05:10:59.524Z)
• OS Version: Darwin x64 16.7.0

Steps to Reproduce:

1. Use yo code to create a simple extension
   
2. Open the new extension in code
3. Open tasks.json and remove the problemMatcher
4. F5

Expected: debugger starts
Actual: debugger does not start. However debugger will start on 2nd F5

More context: I don't expect users to remove the problem matcher in this scenario, but it just illustrates the problem. I have a different project that has the same structure (a launch.json file referencing a background 'preLaunchTask' in tasks.json), but no problem matcher exists that I could use.

[dbaeumer]

The problem is as follows:

• since there is no problem matcher attached no output is scanned for the 10:29:47 AM - Compilation complete. Watching for file changes. message. So the task system doesn't send any start or stop events.
• not sure what to do here. May be debug should have a timeout and if it doesn't receive any events from the task system in n seconds ask the user if he wants to debug anyways.

[weinand]

I don't like the timeout on the debug side. There is always someone who has a long running task that sends no output. In this case a timeout would be wrong or misleading.

If a task is a watcher (which does not have an obvious task end), the user has to make sure that the watcher task communicates back to VS Code that it has finished a "round". If the task is lacking a problem matcher then this is a fundamental configuration problem for a "watcher". So maybe there should be a warning when running such a task.

[isidorn]

Also against a timeout due to a simple question: what is the right time after which we should ask the user? There is no way to design this to be a nice user friendly experince for different tasks

[dbaeumer]

But tasks don't know that they are used as a prelaunch tasks. It is perfectly legal to have a background task that doesn't signal any begin / end. So I can't flag this as a problem :-)

Since debug requires that the task has a problem matcher may be debug should check for this and warn the user. The task might not report any problems if no problem matcher is attached.

[weinand]

Debug doesn't "require" that the task has a problem matcher. It does not even know what a "problem matcher" is.
The only thing debug requires is that a task produces an "end" event of some sort.
How a task achieves this, is an implementation detail of the task.

[dbaeumer]

Discussed this with @weinand and I agree that debug doesn't require a problem matcher. But what could be done is measuring the time until you receive a begin event. If this is not coming lets say in 60 seconds it is very unlikely that the task started correctly. If a begin event is received then debugs should wait for the end event which might never come if things are misconfigured.

[EricJizbaMSFT]

At least in my scenario - I'm perfectly capable of defining 'start' or 'stop' events - I just wish I wasn't required to define those events in a problem matcher

Today I'm defining a problem matcher with a bogus regexp as a workaround, but ideally I would only need to define the 'background' section that has a 'beginsPattern' and 'endsPattern':

{
    version: '2.0.0',
    tasks: [
        {
            taskName: 'Launch Function App',
            identifier: "launchFunctionApp",
            type: 'shell',
            command: 'func host start',
            isBackground: true,
            presentation: {
                reveal: 'silent'
            },
            problemMatcher: [
                {
                    owner: 'azureFunctions',
                    pattern: [
                        {
                            regexp: '\\b\\B',
                            file: 1,
                            location: 2,
                            message: 3
                        }
                    ],
                    background: {
                        activeOnStart: true,
                        beginsPattern: '^.*Stopping host.*',
                        endsPattern: '^.*Job host started.*'
                    }
                }
            ]
        }
    ]
}

[dbaeumer]

@EricJizbaMSFT I agree and there is an issue to move the begin / end pattern into its own property if no pattern is required. But usually the begin / end message is printed by a compiler. That is why we initially added them to the problem matcher.

[weinand]

Based on @dbaeumer's recommendation from above I suggest the following:
After starting a prelaunch task, debug will wait for the "start event". If no start event arrives within 10 seconds we show an error notification "Prelaunch task ${name} cannot be tracked. Abort or debug anyway?".

[lerit]

look forward to this feature

[isidorn]

@EricJizbaMSFT thanks for great repro steps
@dbaeumer @weinand thanks for suggestions on what to do here

[weinand]

@isidorn the error message shows the prelaunch task name as $npm instead of npm because you copied my suggestion from above with the bogus '$' (sorry for giving bad advice):

Please remove the $ and add single quotes so that the name stands out:
Prelaunch task '{0}' cannot be tracked.

We already do this in other places:

BTW, we might want to harmonise the "prelaunch task" as well...

[isidorn]

@weinand silly me, thanks for finding this.

[weinand]

I've changed the message to "The preLaunchTask '{0}' cannot be tracked." to better align it with similar messages about the prelaunch task.

[zajrik]

Is there a way to have it wait longer (even an arbitrary amount of time) for the "start" event? Currently, on my laptop, my pre-launch task that takes only a couple seconds on my desktop takes about 11 seconds, forcing me to press "Debug anyway" for every successful pre-launch compilation simply because it falls a second short of the cutoff.

I'm operating off of the assumption that this task does properly emit the start event when finished given that debugging successfully starts when working on my desktop.

[danielcaldas]

@weinand waiting for the "start event" is a good suggestion, still, we could make it more effective. In my opinion, an improved strategy for this would be to add a pooling mechanism on the "start event" check, this way could have a pre-configured number of retries NR for this pooler verification, and only if all the NR checks for the "start event" failed then we show an error message "The preLaunchTask '{0}' cannot be tracked after '{1}' attempts." This could mitigate cases such as @zajrik mentioned above.