remove lifecycle handling heuristics around parent/child sessions

Since we now have a managedByParent option in DebugSessionOptions we should now consider to remove any previous lifecycle handling heuristics that we added around parent/child sessions.

For details see #128058

[weinand]

@roblourens

I don’t fully understand the original issue that led to all of this, https://github.com/microsoft/vscode/issues/118196. Why are there parent/child sessions in this scenario?

js-debug works differently than node-debug or node-debug2.

In the legacy debuggers we just had one DA corresponding to one debuggee and a parent/child relationship would only occur with a feature like "autoAttachChildProcesses": true, where forked sub processes would result in child debug sessions.

In js-debug there is always a server-like DA that is not talking to a real debugger but instead listens for requests to spawn DAs for the real debugging. This server DA is the parent and all the spawned DAs become its children. With this “reverse” approach features like “autoAttachChildProcesses” or a “Javascript debug terminal” basically come for free.

But this means that even the simplest case (debugging a single node.js program) results in a parent debug session with a single child debug session. To keep what gets rendered in the CALL STACK view compact, VS Code can suppress showing the parent if there is only one child (DebugSessionOption.compact) .

But sending user commands like “Stop” or “Restart” to the correct debug session is more tricky. Some DAs are interested in receiving the commands at the “parent”, so that they can manage the children themselves (like js-debug). Other DAs are OK with receiving the commands directly for the children.

Currently VS Code is using a heuristic where to send a command. But with the introduction of the DebugSessionOption.managedByParent this is no longer necessary.

@connor4312 is this a faithful explanation of js-debug?

Also is there an easy scenario to test with parent/child sessions to see the affect of the code in those linked commands?

With js-debug even the simplest debugging scenario becomes a parent/child scenario. My preferred sample for testing parent/child scenarios is the Cluster program.

[isidorn]

I went through all the usages of session.parentSession and the only ones that might need some rework are:

• https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/debug/browser/debugCommands.ts#L249
• https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/debug/browser/debugCommands.ts#L328

Both of these are respecting the setting debug.showSubSessionsInToolBar. I think they should no longer look at this setting and instead respect the lifecycleManagedByParent flag. Maybe we can even consider deprecating debug.showSubSessionsInToolBar setting.