Debug Attaching seems like it is trying to start it's own server [EADDRINUSE]

[hayfithyan]

I can't seem to connect the debug adapter to my local running node service. My config looks like:

    config = function()
      local dap = require "dap"
      local attach_node = {
        type = "pwa-node",
        name = "Attach to Node",
        request = "attach",
        address = "127.0.0.1",
        processId = require("dap.utils").pick_process,
        cwd = "${workspaceFolder}",
      }

      dap.adapters["pwa-node"] = {
        type = "server",
        host = "localhost",
        port = "9229",
        executable = {
          command = "js-debug-adapter",
          args = { "9229" },
        },
      }

      dap.configurations.javascript = {
        attach_node,
      }
      dap.configurations.typescript = {
        attach_node,
      }
    end,
  }

However when I start my service manually and try to connect using that attatch_node configuration, I get this error from the debug-adapter

[debug-adapter stderr] Error: listen EADDRINUSE: address already in use 127.0.0.1:9229
    at Server.setupListenHandle [as _listen2] (node:net:1463:16)
    at listenInCluster (node:net:1511:12)
    at GetAddrInfoReqWrap.doListen [as callback] (node:net:1660:7)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:111:8) {
  code: 'EADDRINUSE',
  errno: -48,
  syscall: 'listen',
  address: '127.0.0.1',
  port: 9229
}

Which makes me think, the debug adapter is also trying to start it's own instance even though it should just be attaching to the already running instance. Any help would be greatly appreciated.

[josephemorgan]

I'm having a similar issue.

My config looks like this:

local function configure_debuggers()
 local mason_path = vim.fn.glob(vim.fn.stdpath "data" .. "/mason/")

 local dap = require('dap')

 require('dap-vscode-js').setup({
     debugger_path = vim.fn.stdpath('data') .. '/mason/packages/js-debug-adapter',
     debugger_cmd = { 'js-debug-adapter' },
     adapters = { 'pwa-node' },
   })

   dap.configurations.typescript = {
     {
       type = 'pwa-node',
       request = 'launch',
       name = 'Launch Current File (pwa-node)',
       cwd = vim.fn.getcwd(),
       args = { '${file}' },
       sourceMaps = true,
       protocol = 'inspector',
     }
   }

   dap.configurations.javascript = {
     {
       type = 'pwa-node',
       request = 'launch',
       name = 'Launch Current File (pwa-node)',
       cwd = vim.fn.getcwd(),
       args = { '${file}' },
       sourceMaps = true,
       protocol = 'inspector',
     }
   }
end

I get the following error when I try to launch the debugger:

[dap-js] JS Debugger stderr: Error: listen EADDRINUSE: address already in use ::1:8123
    at Server.setupListenHandle [as _listen2] (node:net:1740:16)
    at listenInCluster (node:net:1788:12)
    at GetAddrInfoReqWrap.doListen [as callback] (node:net:1937:7)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:109:8) {
  code: 'EADDRINUSE',
  errno: -98,
  syscall: 'listen',
  address: '::1',
  port: 8123
}

[serranomorante]

Hi! same error address already in use ::1:8123

[TylerBarnes]

I'm having the same issue. I traced it down to this PR microsoft/vscode-js-debug#1771

If I checkout the commit in the vscode-js-debug repo just before that was merged it works perfectly. The commit with the latest working state is 4d7c704d3f07

What I did for now is deleted vscode-js-debug and stopped using mason to install it. I added this to install it with lazy

{
		"mxsdev/nvim-dap-vscode-js",
		dependencies = { "mfussenegger/nvim-dap", {
			'microsoft/vscode-js-debug',
			commit = "4d7c704d3f07",
			build = 'npm i && npm run compile vsDebugServerBundle && mv dist out',
		} }
	}

[TylerBarnes]

Think I figured it out. This line
https://github.com/microsoft/vscode-js-debug/pull/1771/files#diff-c001bf5e0f833fe97f209582262b8009a13146b94426aa7ee943566d6d4c6a16R25

Becomes something like

process.env['NODE_OPTIONS'] =
  (process.env['NODE_OPTIONS'] || '') +
  ' --require /Users/you/.local/share/nvim/lazy/vscode-js-debug/out/src/bootloader.js ';

Before that PR you'd have something like:

  NODE_OPTIONS: '--require /Users/you/.local/share/nvim/lazy/vscode-js-debug/out/src/bootloader.js',

So if you start your node process with NODE_OPTIONS=--inspect or NODE_OPTIONS=--inspect-brk the code in that PR will pass those node options down to child processes which will also start a debug server. I tested this by removing the line in vscode-js-debug that adds process.env['NODE_OPTIONS'] =process.env['NODE_OPTIONS'] || '') + and it works again.

On the latest version if you remove NODE_OPTIONS from this line https://github.com/microsoft/vscode-js-debug/blob/main/src/targets/node/nodeAttacherBase.ts#L15 it will work. So it seems like this behaviour is intentional by the vscode-js-debug team. Not sure what the right fix for this is.

[josephemorgan]

Think I figured it out. This line https://github.com/microsoft/vscode-js-debug/pull/1771/files#diff-c001bf5e0f833fe97f209582262b8009a13146b94426aa7ee943566d6d4c6a16R25

Becomes something like

process.env['NODE_OPTIONS'] =
  (process.env['NODE_OPTIONS'] || '') +
  ' --require /Users/you/.local/share/nvim/lazy/vscode-js-debug/out/src/bootloader.js ';

Before that PR you'd have something like:

  NODE_OPTIONS: '--require /Users/you/.local/share/nvim/lazy/vscode-js-debug/out/src/bootloader.js',

So if you start your node process with NODE_OPTIONS=--inspect or NODE_OPTIONS=--inspect-brk the code in that PR will pass those node options down to child processes which will also start a debug server. I tested this by removing the line in vscode-js-debug that adds process.env['NODE_OPTIONS'] =process.env['NODE_OPTIONS'] || '') + and it works again.

On the latest version if you remove NODE_OPTIONS from this line https://github.com/microsoft/vscode-js-debug/blob/main/src/targets/node/nodeAttacherBase.ts#L15 it will work. So it seems like this behaviour is intentional by the vscode-js-debug team. Not sure what the right fix for this is.

This is awesome, going to test right now.