bug: debugger does not start

[asfaltboy]

Did you check docs and existing issues?

• I have read the documentation.
• I have searched the existing issues.

Neovim version (nvim -v)

0.10.0

Operating system/version

macOS 14.5

Describe the bug

neotest-golang runs a single test, but cannot start debugger for the same test.

Note: neotest-go starts the debugger (though it runs for all tests in the module 😢 ), but neotest-golang fails with an error:

neotest-golang: ...vchenko/.local/share/nvim/lazy/nvim-nio/lua/nio/init.lua:119: The coroutine failed with this message: 
...nvim/lazy/neotest/lua/neotest/client/strategies/init.lua:57: attempt to index local 'instance' (a nil value)
stack traceback:
	...nvim/lazy/neotest/lua/neotest/client/strategies/init.lua: in function 'run'
	...al/share/nvim/lazy/neotest/lua/neotest/client/runner.lua:130: in function '_run_spec'
	...al/share/nvim/lazy/neotest/lua/neotest/client/runner.lua:89: in function <...al/share/nvim/lazy/neotest/lua/neotest/client/runner.lua:88>
stack traceback:
	...ocal/share/nvim/lazy/neotest/lua/neotest/client/init.lua:89: in function <...ocal/share/nvim/lazy/neotest/lua/neotest/client/init.lua:88>
	[C]: in function 'error'
	...vchenko/.local/share/nvim/lazy/nvim-nio/lua/nio/init.lua:119: in function 'gather'
	...al/share/nvim/lazy/neotest/lua/neotest/client/runner.lua:94: in function '_run_tree'
	...al/share/nvim/lazy/neotest/lua/neotest/client/runner.lua:65: in function <...al/share/nvim/lazy/neotest/lua/neotest/client/runner.lua:22>
	[C]: in function 'xpcall'
	...ocal/share/nvim/lazy/neotest/lua/neotest/client/init.lua:84: in function 'run_tree'
	...al/share/nvim/lazy/neotest/lua/neotest/consumers/run.lua:85: in function 'func'
	...chenko/.local/share/nvim/lazy/nvim-nio/lua/nio/tasks.lua:173: in function <...chenko/.local/share/nvim/lazy/nvim-nio/lua/nio/tasks.lua:172>

Steps To Reproduce

1. Start a debugger for a test case
2. An error occurs

Expected Behavior

Should run the debugger

Your Lua setup

Using LazyVim I configure:


return {
  "nvim-neotest/neotest",
  opts = {
    adapters = {
      -- "neotest-go",
      "neotest-golang",
    },
  },
  dependencies = {
    {
      -- {
      --   "nvim-neotest/neotest-go",
      --   extra_args = { "-vet=off" }
      -- },
      {
        "fredrikaverpil/neotest-golang",
        args = { "-vet=off" }
      },
    },
  },
}

[fredrikaverpil]

Please provide a minimal reproducible Go test example.

[asfaltboy]

Check out https://github.com/golang-jwt/jwt , run go build ./... to make sure it builds, then run neovim in the dir and execute a debug test.

[fredrikaverpil]

I cloned down the repo, found a test at random and tried to both run it and then debug it. Works on my machine 😄

It feels like this could be a configuration issue on your end...?

Since LazyVim is already using neotest-golang, I could quite easily try it out here too, and it works for me:

[fredrikaverpil]

Were you able to run a test at all (not debug it)?

Could it be that you haven't enabled debugging in your neotest-golang config with dap_go_enabled = true?

What happens if you run :checkhealth neotest-golang?

[fredrikaverpil]

Instead of letting Neotest error like you observed, I'm now raising an error from neotest-golang (a17f388). So if this was your issue, you should now see another error which is hopefully better att explaining what went wrong.

[fredrikaverpil]

I moved the thread here @asfaltboy as I suspect this to be a configuration issue.

[asfaltboy]

Thanks Fredrik, you're right I thought the config is identical to neotest-go, but didnd't realise I need to pass dap_go_enabled = true to enable debugging. This now works in another repo I have.

With regards to jwt it still doesn't work for me, but might be another issue.

I added it now to my config, and updated to latest release as of now. But sadly, the default package selection still fails for me in jwt, it emits: "go", "test", "-json", "-v", "-race", "-count=1", "/Users/pavel.savchenko/Code/oss/jwt", "-run", "^TestECDSAVerify$" which fails for me on the command line with this message:

directory ../../../Code/oss/jwt outside main module or its selected dependencies

[fredrikaverpil]

Hmmm. That's strange, as I could run (and debug) that test on my machine. Makes me doubt something is wrong in the jwt project.

That capital C in "Code" caught my eye here (and maybe the "." in your username).

In your current setup, what happens if you run:

go test -v -race -count=1 /Users/pavel.savchenko/Code/oss/jwt -run ^TestECDSAVerify$

vs

go test -v -race -count=1 /Users/pavel.savchenko/code/oss/jwt -run ^TestECDSAVerify$

And also, what happens if you clone down the project into a folderpath which contains 1) no capital "C" and/or 2) no period sign and try to run/debug the test from there?

[asfaltboy]

I was able to run it in another path with a dot and capital, then I came back to my dir and it ran fine again... This must be something wrong with my machine, possibly anti-virus protection (this is a company machine, and I think it runs bit defender)

[fredrikaverpil]

I cloned down the project into my macOS user's ~/Public folder and I'm getting a similar error that you had.

If I run the test with capital P it fails. If I run the test with lowercase p it passes. 🤷

[asfaltboy]

There may be more issues with directory/package lookup as well

For instance, I have a large repo, where the tested directory resolves to "./..." which runs, but way way slower than it does from CLI or with neotest-go.

I think the best performing selection for running a single test or a single file can be achieved by passing in the test file path or package directly, relative to the cwd, though it seems preventing it from using package internal names.

So for instance in jwt it would fail with a [build failed]:

go test  -v -race -count=1 -run '^TestECDSAVerify$' ./ecdsa_test.go
# command-line-arguments_test [command-line-arguments.test]
./ecdsa_test.go:141:4: undefined: benchmarkSigning
FAIL	command-line-arguments [build failed]
FAIL

The next best thing would be local dir ./. in the case of jwt, but can be more deeply nested in larger repos.

And failing that, it would be the package name of course.

[fredrikaverpil]

So to be clear, the adapter defaults to ./... for running all tests in a dir or file.

• https://github.com/fredrikaverpil/neotest-golang/blob/main/lua/neotest-golang/runspec/dir.lua#L30
• https://github.com/fredrikaverpil/neotest-golang/blob/main/lua/neotest-golang/runspec/file.lua#L29

It then tries to be more clever and figure out which package correlates to the dir or file. But if it fails, it will use ./... which could be slower, yes.

You can run go list in the folder of your go.mod to see the output used by the adapter so it can translate a folderpath or file path into a package. It sounds like, in your case, this lookup is failing.

I think I will add some more logging today so all this will be easier to look into, by just reading the logs.

[asfaltboy]

Trouble is that it's so verbose on this repo, generating around 500k lines of debug rows per test run...

Hmm, with neotest-go it's not as verbose, I think it must not be doing as much work. It seems all it does is CD into the dir and run go test ./ which seems to work fine for detecting a package. I wonder, would you be up for adding this naive approach as an alternative mechanism for directory/package detection, perhaps behind an option flag?

[fredrikaverpil]

I'm not sure I understood your suggestion on a more naive package detection. Can you explain it in a separate enhancement issue or in a PR?

[fredrikaverpil]

Trouble is that it's so verbose on this repo, generating around 500k lines of debug rows per test run...

Do you mean the logfile gets that big?

[fredrikaverpil]

I added a little utility in this PR that will filter out non adapter related logs: #144

Give it a try if you wish, by setting branch = "log-more" in the adapter opts.

EDIT: now merged into main.