You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If add-ons register for the same pattern, like the RuboCop add-on registering for .rubocop.yml (same as the Ruby LSP), then the server will receive duplicate changes for those patterns
We need to provide a proper API for file watching registration that provides the LSP with the opportunity to:
Register them all at once
Ensure ID uniqueness (it will be a single registration, so that is fixed by default)
Verify that patterns are unique to avoid receiving the duplicate notifications in the first place
I haven't prototyped anything, but I think we may need a breaking change to expose a nicer API to add-ons. Instead of passing the outgoing_queue as a Thread::Queue, it would be better to have our own abstraction so that we can limit what add-ons can pass and ensure that bugs like these cannot happen.
The text was updated successfully, but these errors were encountered:
### 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.
We are currently allowing add-ons to register file watchers freely, but I just realized this is not a good approach for a few reasons.
.rubocop.yml
(same as the Ruby LSP), then the server will receive duplicate changes for those patternsWe need to provide a proper API for file watching registration that provides the LSP with the opportunity to:
I haven't prototyped anything, but I think we may need a breaking change to expose a nicer API to add-ons. Instead of passing the
outgoing_queue
as aThread::Queue
, it would be better to have our own abstraction so that we can limit what add-ons can pass and ensure that bugs like these cannot happen.The text was updated successfully, but these errors were encountered: