RFC: Support for subprocess inspection

[eugeneo]

Chrome DevTools protocol has a domain for working with subtargets (https://chromedevtools.github.io/debugger-protocol-viewer/tot/Target/). In the browser case, subtargets are be web/service workers, nested IFrames, etc.

In the Node case a subtarget may be a forked Node process. Introducing such a domain would remove a need to separately connect to forked instances.

Current proposal is to introduce a dedicated inspector pipe between parent and child process (in addition to current ipc pipe). This way there will be no need to look for a free port and to start up inspector HTTP server in every subprocess.

[Qard]

That would be very cool. I wonder a bit about backwards compatibility importance though. Is there any existing tooling that deals with debugging a cluster, for example?

[auchenberg]

The target domain in CDP 1.2 is marked as experimental, and after recent conversations with the Chrome DevTools team, it's my understanding that they aren't too happy about the API design, as it's essentially embedded CDP commands within the Target.sendMessageToTarget. This should probably be factored into the considerations of using this existing API.

(@paulirish or @pavelfeldman can probably clarify)

[jkrems]

I implemented something like it when I was working on bugger[1]. As long as the worker is spawned via child_process#fork (e.g. using cluster), it's relatively straight-forward. The fact that it's just "CDP over CDP" makes the implementation really simple but I get why it isn't the most elegant API. One of the downsides was that workers weren't treated as fully featured debug targets in the UI (understandable given that they're not on the web).

[1] https://github.com/buggerjs/bugger/blob/master/lib/agents/worker/index.js

[eugeneo]

@Qard this would be Inspector-specific (e.g. require a --inspect). I don't think it would be possible to use existing IPC pipe (not sure what interplay would be if V8 is suspended on a breakpoint and such).

So, it most likely will be some new command line flag (--inspect-pipe=<path/to/pipe>?) I don't think it would have impact on backwards compatibility...

[pavelfeldman]

Target API is indeed not the most elegant extensibility implementation, but there are things that speak in its favor:

• it is very simple and hackable
• it proved to work for us in production for more than a year (it was powering workers and service workers before got renamed into Target)
• it allows nested targets of various types

So I think that we could stick with it. Supporting it in Node means making it public. Let us review it and present to you.

[Qard]

I wonder if it'd be possible to provide an API for the targets feature to programmatically allow linking frontend to backend or linking isolated nodes in a distributed system. It'd be very cool to be able to inspect multiple levels of the stack at the same time, in the same UI.

[joshgav]

Seems like this would be ideal for process managers like PM2 and indeed anyone relying on the cluster module and multiple processes per system. Right now they'd have to add args to child_process/cluster.fork, as e.g. here: https://github.com/nodejs/node/blob/master/test/parallel/test-cluster-debug-port.js

FWIW seems the name of the domain should be "Proxy" or "InspectorProxy" rather than "Target" though, as the original debuggee/target is in fact acting as that.

@Qard

allow linking frontend to backend

+1, would be great to somehow discover and be able to automatically attach to backend (i.e. Node) from frontend.

[refack]

Ref: nodejs/node#12941

[eugeneo]

This had been implemented some time ago.