-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Fix ruff server
hanging after Neovim closes
#11291
Conversation
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.
Do you think this would work as expected if we were sending messages via the LSP protocol? Or same issue?
That wouldn't work because the I/O with the client has shut down at the point where we log this. However, it would at least fail instantly instead of just waiting forever. |
|
How can we avoid this in the future? It seems error prone to rely on tracing not being used after the main loop ends (it may even be a dependency that writes a trace, maybe even a third party dependency |
Any ideas? I don’t understand the root of the problem well-enough. |
Not understanding the root cause is what makes me wary of the fix. It's a good fix to unblock users but it seems fragile to me long term. |
I can do some further investigation into why the tracing log was blocking. |
the |
Summary
A follow-up to #11222.
ruff server
stalls during shutdown with Neovim because after it receives an exit notification and closes the I/O thread, it attempts to log a success message tostderr
. Removing this log statement fixes this issue.Test Plan
Track the instances of
ruff
in the OS task manager as you open and close Neovim. A new instance should appear when Neovim starts and it should disappear once Neovim is closed.