ruff server not closing with neovim instances #11207
Comments
|
Good catch! Thanks for opening this issue. It's happening on macOS as well. And it isn't specific to Neovim, I'm seeing it in VS Code as well. Screen.Recording.2024-04-30.at.13.35.37.mov |
## Summary Fixes #11207. The server would hang after handling a shutdown request on `IoThreads::join()` because a global sender (`MESSENGER`, used to send `window/showMessage` notifications) would remain allocated even after the event loop finished, which kept the writer I/O thread channel open. To fix this, I've made a few structural changes to `ruff server`. I've wrapped the send/receive channels and thread join handle behind a new struct, `Connection`, which facilitates message sending and receiving, and also runs `IoThreads::join()` after the event loop finishes. To control the number of sender channels, the `Connection` wraps the sender channel in an `Arc` and only allows the creation of a wrapper type, `ClientSender`, which hold a weak reference to this `Arc` instead of direct channel access. The wrapper type implements the channel methods directly to prevent access to the inner channel (which would allow the channel to be cloned). ClientSender's function is analogous to [`WeakSender` in `tokio`](https://docs.rs/tokio/latest/tokio/sync/mpsc/struct.WeakSender.html). Additionally, the receiver channel cannot be accessed directly - the `Connection` only exposes an iterator over it. These changes will guarantee that all channels are closed before the I/O threads are joined. ## Test Plan Repeatedly open and close an editor utilizing `ruff server` while observing the task monitor. The net total amount of open `ruff` instances should be zero once all editor windows have closed. The following logs should also appear after the server is shut down: <img width="835" alt="Screenshot 2024-04-30 at 3 56 22 PM" src="https://github.com/astral-sh/ruff/assets/19577865/404b74f5-ef08-4bb4-9fa2-72e72b946695"> This can be tested on VS Code by changing the settings and then checking `Output`.
|
The problem persists in neovim after ruff 0.4.3. |
|
Hi @snowsignal I am still seeing this problem with ruff 0.4.5 and neovim 0.9.5 on Linux Fedora 39. |
|
@danielhollas Hi, can you open a new issue with the logs? I tried it on macOS with Ruff 0.4.5 and Nvim 0.10.0 and it works as expected. Can you also try it with Nvim 0.10.0? |
|
Hi @dhruvmanila 👋 happy to do more investigation, but would you mind explaining how to get the logs? (Sorry, I am new to neovim, and LSP in general). |
|
No worries. You can find the file path using |
Ruff: 0.4.2
OS: Windows 10
Terminal: Wezterm - Latest Nightly
Shell: Powershell Core 7.4.2
Neovim Build - Latest nightly (and each nightly over the past 3-4 days I've noticed this)
Hello All...I feel like this is going to be kind of a barebones bug report and I am sorry about that.
I have been using the new ruff server in lieu of ruff_lsp with neovim and noticed that there might be an issue with ruff.exe not always being terminated when you close a neovim instance. I have tried to consistently reproduce the bug and I have failed but I noticed that every once in a while I can check my processes and there will be a plethora of ruff.exe running even though I might only have 1 or 2 neovim instances or buffers open.
I don't think I ever noticed this during my time using ruff_lsp.
Love what you all do, just wanted to try and keep you aware since ruff server is in alpha.
The text was updated successfully, but these errors were encountered: