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
vinistock opened this issue
Jan 14, 2025
· 0 comments
Labels
bugSomething isn't workingpinnedThis issue or pull request is pinned and won't be marked as staleserverThis pull request should be included in the server gem's release notes
We currently have request cancellation implemented incorrectly. We are pushing the requests and their cancellation notification all in the incoming queue. Since Thread::Queue#pop pops items in the order in which they were pushed, we always see the cancellation after we already ran the request, which completely defeats the whole purpose of cancelling it.
We tried fixing that in #2939, but it caused issues for NeoVim #3019. We need to review our understanding of what needs to happen with a cancellation and ensure it's working properly.
What we need to clarify is if a request is cancelled, what should the server return once we get to that request? Current understanding is the error code RequestCancelled, but maybe it shouldn't return anything and should only return that error is the request is tried? In essence, what are the expectations from the server for the first response for a cancelled request and any subsequent ones?
The text was updated successfully, but these errors were encountered:
vinistock
added
bug
Something isn't working
pinned
This issue or pull request is pinned and won't be marked as stale
server
This pull request should be included in the server gem's release notes
labels
Jan 14, 2025
bugSomething isn't workingpinnedThis issue or pull request is pinned and won't be marked as staleserverThis pull request should be included in the server gem's release notes
We currently have request cancellation implemented incorrectly. We are pushing the requests and their cancellation notification all in the incoming queue. Since
Thread::Queue#pop
pops items in the order in which they were pushed, we always see the cancellation after we already ran the request, which completely defeats the whole purpose of cancelling it.We tried fixing that in #2939, but it caused issues for NeoVim #3019. We need to review our understanding of what needs to happen with a cancellation and ensure it's working properly.
What we need to clarify is if a request is cancelled, what should the server return once we get to that request? Current understanding is the error code
RequestCancelled
, but maybe it shouldn't return anything and should only return that error is the request is tried? In essence, what are the expectations from the server for the first response for a cancelled request and any subsequent ones?Relevant spec page: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#cancelRequest
The text was updated successfully, but these errors were encountered: