-
Notifications
You must be signed in to change notification settings - Fork 4
Fixes an issue with the dotnet executable not being killed #34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes an issue with the dotnet executable not being killed #34
Conversation
@@ -33,7 +33,7 @@ local function start_server(dll_path, mtp_env) | |||
logger.debug("neotest-vstest: Accepted connection from mtp") | |||
mtp_client = client | |||
client:read_start(function(err, data) | |||
assert(not err, err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you need to comment out this line? When I run it, it seems to run just fine with the assert
present
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get the following error during the test discovery and when a test finishes. I believe it happens anytime the client would be created.
Personally, I don't understand why it happens, especially if it isn't happening on a non windows machine. For me, it happens every time even though the tests run to completion
Error executing callback:
...ta/lazy/neotest-vstest/lua/neotest-vstest/mtp/client.lua:36: ECONNRESET
stack traceback:
[C]: in function 'assert'
...ta/lazy/neotest-vstest/lua/neotest-vstest/mtp/client.lua:36: in function <...ta/lazy/neotest-vstest/lua/neotest-vstest/mtp/client.lua:35>
[C]: in function 'resume'
.../AppData/Local/nvim-data/lazy/nvim-nio/lua/nio/tasks.lua:118: in function 'cb'
.../AppData/Local/nvim-data/lazy/nvim-nio/lua/nio/tasks.lua:183: in function <.../AppData/Local/nvim-data/lazy/nvim-nio/lua/nio/tasks.lua:182>
Error executing callback:
...ta/lazy/neotest-vstest/lua/neotest-vstest/mtp/client.lua:36: ECONNRESET
stack traceback:
[C]: in function 'assert'
...ta/lazy/neotest-vstest/lua/neotest-vstest/mtp/client.lua:36: in function <...ta/lazy/neotest-vstest/lua/neotest-vstest/mtp/client.lua:35>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, there might be some timing issue going on here, where the LSP kills the connection before the server does.
Might have to look into a different kind of error handling if the assert puts the plugin into a zombie state
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll mess around until I no longer get that assert error unless you had another idea for the error handling
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've thought a little about this and I think removing the assert is fine – the error handling is not really working as intended for the MTP server at the moment regardless.
Ideally, any assertion errors in the MTP "proxy" process should trigger a shutdown of the LSP client but at this stage it just crashes the proxy process.
If you want to play around with the error handling it would be very welcomed but I am also fine with getting this merged if the assert is just replaced with a log statement so we can track when errors are thrown.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the error was important. The client is being killed prematurely and not all of the test discovery results are being captured
Looks like client:request_sync
has a default timeout of 1s so even when ignoring the error I noticed all of my tests weren't always there. I changed this to 30s for now
I also got that assert changed to a logger.warn
1d473b0
to
ef7509c
Compare
Nice find on the lsp request timeout! I'll just fix the linting issues and get this merged in. Thanks 🙌🏻 |
I was running into an issue where the dotnet process was not being killed properly. This is an issue on Windows because if the process stays around, the dll is locked to that process causing every subsequent rebuilding to fail.
I think this PR might need a little work as I had to remove an assertion ensuring no errors in the client:read_start method.