Skip to content
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

Fail requests that are searching for a non existing position #2938

Conversation

vinistock
Copy link
Member

@vinistock vinistock commented Nov 29, 2024

Motivation

This is an attempt to handle and better understand #2446

We're seeing the server get stuck sometimes and I suspect that what's happening is the following:

  1. A position request gets triggered, like completion, looking for a certain spot in the code
  2. The code changes right as we start locating the position
  3. Ruby switches threads and we process the text edit before finishing finding the specified position
  4. Since now the document is in a different state, that position is no longer valid and it may lead to infinite loops

I propose we start raising when we fail to locate a position in the document and then we fail the request. This will hopefully help us better understand what's happening.

Implementation

Started raising if the scanner position is already past the document range, which may happen if we modify the document exactly as we're searching for the position.

Automated Tests

Added tests.

Copy link
Member Author

This stack of pull requests is managed by Graphite. Learn more about stacking.

@vinistock vinistock added server This pull request should be included in the server gem's release notes bugfix This PR will fix an existing bug labels Nov 29, 2024 — with Graphite App
@vinistock vinistock marked this pull request as ready for review November 29, 2024 19:05
@vinistock vinistock requested a review from a team as a code owner November 29, 2024 19:05
lib/ruby_lsp/document.rb Show resolved Hide resolved
lib/ruby_lsp/server.rb Outdated Show resolved Hide resolved
@vinistock vinistock force-pushed the 11-29-fail_requests_that_are_searching_for_a_non_existing_position branch from fe13536 to 57dc835 Compare November 29, 2024 19:49
@vinistock vinistock merged commit 0d421a6 into main Nov 29, 2024
36 checks passed
Copy link
Member Author

Merge activity

  • Nov 29, 3:26 PM EST: A user merged this pull request with Graphite.

@vinistock vinistock deleted the 11-29-fail_requests_that_are_searching_for_a_non_existing_position branch November 29, 2024 20:26
vinistock added a commit that referenced this pull request Nov 29, 2024
### Motivation

While working on #2938, I noticed that our request cancellation response was incorrect. The spec determines that requests that got cancelled by the client need to return an error using the code for request cancelled ([see here](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#cancelRequest) and see `RequestCancelled` [here](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#errorCodes)).

### Implementation

Started returning an error with the right code, rather than a response with a `nil` body.

I also started running cancel notifications directly in the main thread without pushing it to the queue, which was another mistake. If we put that notification in the queue, then we're guaranteed to only process them **after** we finish running requests, which is useless. We need the ability to process them as soon as we receive the notification, so that we have enough time to cancel the requests.

### Automated Tests

Added a test to verify this.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugfix This PR will fix an existing bug server This pull request should be included in the server gem's release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants