Add postDebugTask to debugger launch.json

[WebFreak001]

There is preLaunchTask already which runs a task right before debugging, it would be cool also having a postDebugTask which would run a task when finishing debugging.

Users could then provide a custom start server and stop server task for example.

[weinand]

duplicate of #2405

[newbrain]

Hi,
are you sure it's a duplicate?
The postDebug task should not run once the debugger is started, but rather when it's ended (i.e. when the "Stop" red sqare icon is clicked).
The idea behind the proposal, that I originally sent to the native gdb extension, is to have a clean up task that can, e.g., stop debug servers.

[weinand]

@newbrain you are right.

[MeirionHughes]

Something like this would make clean up after transpiling (for debugging) a bit easier.

[rei-vilo]

Any update on this postLaunchTask feature? Thank you!

[isidorn]

To be honest I am not undestadning how this is not a duplicate of #2405

All in all, this is still on the backlog. And if demand increases we can consider introducing it in one of the coming releases.

[newbrain]

@isidorn:
#2405 request that a task be started after the launch, so AFAICU, when the debug session is still active.

This one, instead, is asking for a task to be started when the debugging session is terminated ("Stop" button clicked): quite the opposite.

My use case: cleanly stopping a local debug server process (OpenOCD) when debugging embedded code, so that the e.g. DUT is properly reset.

As for #2405, I used a workaround: start a background script with a "reasonable" delay.

[isidorn]

@newbrain Got it. Thanks for the explanation,

[weinand]

@isidorn issue #2405 asks for a hook to launch something (e.g. a browser) after the debug session has started whereas this issue asks for a hook when the debug session has ended.

I believe that this request is actually more important than #2405 because that one can be emulated by using a delay.

[MeirionHughes]

Main problem at the moment is that there is no way to clean up after debugging ts-compiled code, which all needs to be on the file system in order for vscode to find it. We either need a way to clean up after debugging (this issue), or a way to have vscode debug without the js and map file on the fs.

[weinand]

@MeirionHughes any suggestions how VS Code could support debugging without js and map files on the filesystem?

[MeirionHughes]

Well I'm currently using webpack-dev-server quite a lot, and it keeps everything in memory and serves up those files when requested by chrome.

In principle, all you'd really need is

• a webpack plugin that calls
• a vscode server API to supply and update the sourcemaps files (and paths).

whenever the in-memory source/sourcemap is compiled by webpack it could then continually update vscode via the API.

I would imagine the main innards of how vscode deals with the source-mapping would be unaffected - although perhaps it would need testing to make sure you can actually update the sourcemaps on the fly. For example: hot-module reloading where chrome/chrome-debugger won't actually be refreshing the whole page.

[xinyanmsft]

Having a Post debug task is very help for us to clean up remote connections.
Scenario:
We automate some remote debugging scenario by having the prelaunch task establish a SSH connection (port forwarding) to the remote host. The problem now is, we don't have a good way to know when to safely clean up this connection after debugging stops. There is no way to get that event from an extension as well.
If there is a post debug task, we can use it to reliably clean up remote connections.
@isidorn @weinand

[G1itcher]

Would the team consider an external contribution for this?

[isidorn]

@G1itcher yes PRs are welcome, however before writing code feel free to just create a PR with a proposed solution. Once we agree on the structure we can start coding.
If you prefer to code you can just start with that however be aware that we might reject it
Code pointer https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/debug/electron-browser/debugService.ts#L880

Also ping me on the pr. Thanks!

[cleidigh]

@G1itcher
Did you decide to work on this? If not let me know as I can do a PR also.

[G1itcher]

Hi @cleidigh. Unfortunately my situation has changed and I've had 0 free time to sit down and look at this.

[isidorn]

I started looking into this "postDebugTask". This task will be launched when a debug process ends, which basically means when you stop debugging or when you restart your session.
preLaunchTask also gets run on restart so I think this is consistent.

How should we call this? Is "postDebugTask" a good name, how about "postLaunchTask"?
How to make it clear that users do not confuse it with #2405 since both @weinand and me confused it a couple of times.

An alternative to adding a new string field is adding a structured object, something like:

"task": {
  "name" : "foo",
  "whenToExecute": "preLaunch" | "postLaunch" | "onSessionEnd"
}

The upside of this is that it makes it a bit clearer when it will be executed and we can also cover #2405. Downside is that strucutred objects are more complex.

Let me know what you think @weinand

[newbrain]

@isidorn:
"onSessionEnd" is quite self-explicative, I prefer it to my original proposal of "postDebug(Task)".
If a structured object is not used, "onSessionEndTask" seems quite right.

Thanks for picking this up.

[weinand]

@isidorn since we already have a "preLaunchTask" I suggest that we continue to use this naming scheme (and avoid the structured object and the "on*" style). I still like the name "postDebugTask".
And "postLaunchTask" is already reserved for #2405.

Restart behaviour: we have two "restart" mechanisms:

1. User presses "Restart" button
2. launch config uses "restart" attribute and session is restarted automatically.

I'm pretty sure that "postDebugTask" must not be called in the second case.
But I'm not completely sold that it should be called in the first case.

[isidorn]

I have pushed the initial support for this. Try it out in tomorrow's vscode insiders and let us know what you think.

@weinand what you are saying makes sense, however I think the use case is that people want to deconstruct whatever they contructed in preLaunchTask. So I think this should run symetrical to preLaunchTask. As a seperate discussion we can figure out if preLaunchTask should be run on restart (currently it does)?

A seperate issue on my end is that I do not know what is the reason that a session stopped, or started so in both those I run preLaunch or postDebug task.

I am open to changing this but pushed a first version so we get some feedback.

[weinand]

@isidorn you said:

I do not know what is the reason that a session stopped, or started so in both those I run preLaunch or postDebug task.

This is not true for the "restart" case (2. from above). In this case you receive a "restart" attribute in the "terminate" event, so you could know that a "preLaunchTask" and "postDebugTask" is not needed for an automatic "restart".

I don't think that Docker users want to shutdown and relaunch a Docker session on every source code edit.

@chrisdias @WebFreak001 @newbrain what do you think?

[isidorn]

@weinand I did not mean it is not possible, just my code is structured in such a way that I do not have that knowledge when I am reacting on seassion has ended event.
As I mentioned above I am open to changing this.

[isidorn]

@weinand also it seems than for that scenario we should also not run the preLaunchTask again. So it still feels to me preLaunchTask and postDebugTask are "symetric".

[rei-vilo]

That's great news. I'll try the Insider version when it is released!

The use case I have is about debugging MCUs.

• Launch the GDB server (OpenOCD, JLinkGDBServer or other) with preLaunchTask,
• Perform the debugging session,
• Once the debugging session is completed, close it and stop the GDB server with postDebugTask.

Some GDB clients allows to start the server from the GDB clients and to stop it when closing the debugging session, but not all. However, even in that case, I haven't figured out how to set all those parameters on the launch.json file, as the client tries to connect to the server before it starts.

[rei-vilo]

@isidorn

Could preLaunchTask be called preDebugTask, either as a new name or a synonym for preLaunchTask?

[isidorn]

@rei-vilo no, since that would be a breaking change.

[weinand]

@rei-vilo let's talk about semantics first, and then discuss name changes.

@isidorn yes, preLaunchTask should not be called on automatic "restart" (case 2). In the Docker scenario (https://github.com/Microsoft/vscode-recipes/tree/master/Docker-TypeScript) we are lucky and survive multiple activations of the preLaunchTask because it is a background watcher task anyway.

[isidorn]

@weinand I have pushed a change that both preLaunch and postDebug task are not being run on automatic restarts.
Let's try it out and then we can decide if they should be run for explitcit user restarts - currently they are being run.
Thanks

[weinand]

Great, thanks. I'll try my scenarios tomorrow.