Support debugging actual remote servers #129

New issue

Open

opened 2025-11-03 12:33:06 +03:00 by antoineco · 2 comments

antoineco commented

2025-11-03 12:33:06 +03:00

(Migrated from github.com)

dap-go always assumes that a local dlv instance is running, even when the remote + attach mode is selected in the debug configuration.

This currently prevents attaching to a Delve server running on a different host over TCP (including on localhost over a secure tunnel). For instance, dap-go currently tries to find a dlv process when it receives the following configuration:

{
    "name": "Attach through SSH tunnel",
    "type": "go",
    "request": "attach",
    "mode": "remote",
    "host": "127.0.0.1",
    "port": 2345
}

Instead of connecting to the host over TCP, dap-go fails with:

Error on attach: Failed to attach: no debugger found

I work around this issue by bypassing dap-go entirely when both host and port are set in remote mode:

local dap = require "dap"
local dap_go_adapter = dap.adapters.go
dap.adapters.go = function(callback, client_config)
  if client_config.mode == "remote" and client_config.host and client_config.port then
    callback {
      type = "server",
      host = client_config.host,
      port = client_config.port
    }
    return
  end
  dap_go_adapter(callback, client_config)
end

I think it is sensible. I cannot think about a good reason for attempting to find a dlv process when both host and port are set and the remote mode is selected.

Would you accept a PR to adopt this behavior in dap-go?

`dap-go` always assumes that [a local `dlv` instance is running](https://github.com/leoluz/nvim-dap-go/blob/b4421153ead5d726603b02743ea40cf26a51ed5f/README.md?plain=1#L170-L194), even when the `remote + attach` mode is selected in the debug configuration. This currently prevents attaching to a Delve server running on a different host over TCP (including on `localhost` over a secure tunnel). For instance, `dap-go` currently tries to find a `dlv` process when it receives the following configuration: ```json { "name": "Attach through SSH tunnel", "type": "go", "request": "attach", "mode": "remote", "host": "127.0.0.1", "port": 2345 } ``` Instead of connecting to the host over TCP, `dap-go` fails with: ``` Error on attach: Failed to attach: no debugger found ``` I work around this issue by bypassing `dap-go` entirely when both `host` and `port` are set in `remote` mode: ```lua local dap = require "dap" local dap_go_adapter = dap.adapters.go dap.adapters.go = function(callback, client_config) if client_config.mode == "remote" and client_config.host and client_config.port then callback { type = "server", host = client_config.host, port = client_config.port } return end dap_go_adapter(callback, client_config) end ``` I think it is sensible. I cannot think about a good reason for attempting to find a `dlv` process when both `host` and `port` are set and the `remote` mode is selected. Would you accept a PR to adopt this behavior in `dap-go`?

booxter commented

2025-11-25 17:31:46 +03:00

(Migrated from github.com)

Is it to address the same issue as in https://github.com/leoluz/nvim-dap-go/pull/106 ? (I'm using the PR successfully with a devspace managed remote debugger).

antoineco commented

2025-11-25 17:42:20 +03:00

(Migrated from github.com)

It seems similar, although there could be valid cases for wanting to attach to a local delve server using the remote mode but without defining a host and/or port, so hijacking remote entirely seems extreme.

It seems similar, although there could be valid cases for wanting to attach to a local delve server using the `remote` mode but without defining a host and/or port, so hijacking `remote` entirely seems extreme.

👍 1