Support dynamic port assignment via --inspect-port=0

[auchenberg]

It's possible to start Node with node --inspect-port=0 that assignes a dynamic port to the inspector server.

When using it together with a dynamic attach config like:

        {
            "type": "node",
            "request": "attach",
            "name": "Node",
            "processId": "${command:PickProcess}",
            "protocol": "inspector",
            "trace": "verbose"
        }

We end up failing to attach, as we try on the default port

Discovering targets via http://127.0.0.1:9229/json
HTTP GET failed: Error: connect ECONNREFUSED 127.0.0.1:9229

but the Inspector server is running the dynamically assigned port

Find the server at: http://localhost:3001/
Debugger listening on ws://127.0.0.1:51514/64e041f8-0433-4d33-9d11-408359869e84
For help see https://nodejs.org/en/docs/inspector

Idea: When the given process has been selected, attach to the strout, parse the output to find the used port. use that for attach

[roblourens]

Didn't even know about that feature, but this is easy to support. cc @weinand

[auchenberg]

Me neither, learned about it in nodejs/node#16872 (comment)

[weinand]

Hmmm. Since the DA is attaching (and not launching), how can we read the stdout of the debuggee in order to detect the port?

In addition, attaching by process ID is useful if node has been started without any debug/inspect arguments. So if we have to use node --inspect-port=0 upfront this defeats the purpose because then we could use node --inspect=12345 instead and would not have to use the process ID at all...

But may be I'm not really understanding this feature. It's too late... :-)

[roblourens]

I skimmed this and assumed the launch config had the port in it.

If we have to detect the port from stdout then we would have to use some platform-specific method of getting the stdout of a process that isn't a child process. I have no idea how to do that on windows, I don't even know if it's possible. It also seems like there could be issues with node's debug output getting mixed in with output from the user code.

[roblourens]

It looks easy on linux, but the Mac solution is scary: https://stackoverflow.com/questions/3425340/how-can-i-capture-the-stdout-from-a-process-that-is-already-running

[auchenberg]

@weinand The scenario here is that --inspect-port=0 could have been passed to the process, and therefore our default SIGUSR1 logic doesn't work. This is relevant to the Node on Azure production debugging case, where there might be multiple Node processes running and dynamic port assignment is needed. See linked Node issue.

[weinand]

We already have code in node-debug that detects a port based on a process ID: https://github.com/Microsoft/vscode-node-debug/blob/424c7760fd197e29ad7a8bd20234d9dbbd534163/src/node/extension/protocolDetection.ts#L154

And please note that the SIGUSR1 mechanism only works locally. So you cannot send signals to a remote process.

[june07]

Because this is somewhat related, I'm linking to the PR: #235

Would like to get some additional feedback regarding this. Thanks @roblourens so far for your assistance as well.

[connor4312]

@roblourens following up on this and what @weinand mentioned, it seems like (if we still want to do this), the approach would be:

1. Adding a similar getOpenPortsForPidUnix, then top-level getInspectorPortForPid which grabs the process' ports
2. If there's more than one, filtering for which one of those is the inspector by calling GET localhost:<port>/json (If the user is building a web server, they will have additional open ports.) This has the potential of causing side-effects on the target server but I'm unsure that there's a better way to identify the correct port.
3. Calling getInspectorPortForPid in that event that we see --inspect-port=0 in analyseArguments

Thoughts?