nvim-neotest / neotest

An extensible framework for interacting with tests within NeoVim.
MIT License
2.12k stars 105 forks source link

fix: Use buffered stdout in the integrated strategy #413

Closed HeartANDu closed 2 weeks ago

HeartANDu commented 1 month ago

When I ran Golang tests for a whole suite (or for a file), I often encountered that either the plugin hung up or (if using neotest-golang) I was getting the error message:

neotest-golang: ...i.zotov/.local/share/nvim/lazy/nvim-nio/lua/nio/init.lua:119: The coroutine failed with this message: Task was cancelled
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'
        ...i.zotov/.local/share/nvim/lazy/nvim-nio/lua/nio/init.lua:119: in function 'gather'
        ...al/share/nvim/lazy/neotest/lua/neotest/client/runner.lua:153: in function '_run_broken_down_tree'
        ...al/share/nvim/lazy/neotest/lua/neotest/client/runner.lua:79: 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:73: in function 'func'
        ....zotov/.local/share/nvim/lazy/nvim-nio/lua/nio/tasks.lua:173: in function <....zotov/.local/share/nvim/lazy/nvim-nio/lua/nio/tasks.lua:172>

Turns out, that output of commands running in the background sometimes breaks due to not writing the whole thing. I added an option to use buffered output when running commands, so no output is lost when written to a temporary file.

rcarriga commented 3 weeks ago

Sorry I'm not clear on what the exact issue here is. Can you explain why waiting for the stream to be closed fixes your problem?

HeartANDu commented 3 weeks ago

I'm not sure why that happens in particular, but as the async task writes the command output to a temporary file, it sometimes doesn't write the whole output. Since the output of the test command is JSON encoded, decoding of the result breaks. That's why I added waiting for the stream, and decoding doesn't break anymore.

rcarriga commented 2 weeks ago

Thanks for the MR but I'm not going to merge this as it'll mean that the process output won't be visible while it's running which is not acceptable.

This is a bug in the strategy in that it doesn't wait for all of the output before returning but the fix will need a bit of fiddling. Feel free to open an issue