Node debug launch flow

When debugging node application with request = “launch”, does theia node debugger functionality rely somehow on finding the OS process that was launched?

[original thread by amiramw]

I don’t think so, launch means that the debug adapter is responsible to start the debuggee process directly. But one can check implementation of vscode node debug adapter.


I’m just adding a bit background for this question.

  1. We have a Node launch configuration (in .vscode/launch.json) with “runtimeExecutable”: “npx”. When running this configuration, npx is invoked on the other (not theia’s) container and invokes node on this other container (this is by design and we have some infrastructure to support it). Debugging this configuration succeeds to run the application, but debugger fails with “Error: connect ECONNREFUSED”.

  2. I added a Node attach configuration and debugger was successfully attached to the application which was started in 1.

  3. If I change the configuration in 1 to regular node launch configuration(node is invoked on the other container as well), the debugger works.

relevant code seems to be here:

It looks like 2 things happen:

  • start a process with inferred hostname and port to expose inspector
  • try to attach to these hostname and port within some timeout

strange that it has wsl prefix, but i cannot find other code spawning a node process to debug

try to add address property to your launch configuration which points to ip address of another container where program will be executed, see for remote debugging

I wonder how attach works for you then? Do you specify address of another container as well? or requests to localhost tunneled to a proper container for debug port?


No, only port:
“type”: “node”,
“request”: “attach”,
“name”: “Attach”,
“port”: 9978

Maybe timing issue, the process gets too long to start. As far as I understood attach configuration has 9978 port as well. If you can attach then everything should be reachable. There should be a way to configure timeout as well.


I think we need to add to the code you sent some possibility to wait till the process is up (including all child processes) after spawn and call attach only after it. Or add possibility for more retries in attach. Or both.
I see in the code, it should perform retries while timeout. I tried yesterday to configure a timeout, but it didn’t help - investigating it.

You will need to file a feature request here:


Looks like it retries only one time in _attach():

no, it keeps trying to reconnect each 200ms till it is within timeout, if next reconnect fails then error event handler is called which tries to reconnect again and so on


Yes, you are correct. I’ve already understood it. Thanks!


Where I can see the relevant logs?

sorry, i don’t know which logs you mean, this code does not log anything, except sending error messages to the client

if there are any logs they should be visible in Theia backend process