-
Notifications
You must be signed in to change notification settings - Fork 179
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
Notify file events failed - Client is not running #3137
Comments
@mioruggieroguida Is this a large project? Roughly how many Ruby files? |
@andyw8 Maybe this helps cloc --include-lang=Ruby .
890 text files.
580 unique files.
548 files ignored.
github.com/AlDanial/cloc v 2.04 T=0.41 s (921.0 files/s, 123854.7 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Ruby 374 6408 11425 32463
-------------------------------------------------------------------------------
SUM: 374 6408 11425 32463 The above does not include gems |
Thank you for the issue, #3144 will fix it. |
### Motivation Closes #3137 We were using the same registration ID for two different file watchers. That made VS Code override the entry, but one of them became a dangling object that didn't get appropriately cleaned up when the LSP shuts down. Because that old file watcher was still active, the LSP client itself was not cleared either as a reference was still being held and then notifications for `didChangeWatchedFiles` were sent to a client that was already stopped, resulting in the `Notify file events failed` message. We should always use unique IDs when registering file watchers. ### Implementation I did 3 small things: 1. Ensured unique IDs for registering the watchers 2. Started watching `.rubocop`, which we watched before but I missed in my refactor PR 3. Started ensuring that we're only processing changes once The last point is necessary because add-ons may register for watching the same patterns as one another or as the Ruby LSP and that results in duplicate changes being sent to the server. The most optimal solution is #3145, but that is going to require more effort, so let's just fix the issue for now. ### Automated Tests Added a test and verified manually that the issue is gone.
…3142) ### Motivation While studying #3137, I noticed there were some disposables not being handled properly. Whatever we push to `context.subscriptions` will only be disposed when the extension is deactivated, which means we continue to waste memory and resources unnecessarily. We need the client and workspace to better own their disposables. ### Implementation I tried minimizing the times where we invoke `context.subscriptions`, so that problems of this nature are easier to spot. There were two command registrations that were leaking and two client hooks.
Just installed 0.9.2 and this is still happening. I noticed that the PR was merged.
|
v0.9.2 is the extension version. This bug was in the server and is released in v0.23.9. You can follow these instructions to upgrade the server or wait until an automatic upgrade occurs. |
Description
Ruby LSP Information
Ruby LSP Information
VS Code Version
1.96.4
Ruby LSP Extension Version
0.8.20
Ruby LSP Server Version
0.23.6
Ruby LSP Add-ons
Ruby Version
3.2.2
Ruby Version Manager
rbenv
Installed Extensions
Click to expand
Ruby LSP Settings
Click to expand
Workspace
User
Reproduction steps
Code snippet or error message
The text was updated successfully, but these errors were encountered: