8000 Revert "update vscode-languageclient with LSP 3.17 support (#6492)" by froydnj · Pull Request #6501 · sorbet/sorbet · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Revert "update vscode-languageclient with LSP 3.17 support (#6492)" #6501

8000
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

Merged
merged 2 commits into from
Oct 21, 2022

Conversation

froydnj
Copy link
Contributor
@froydnj froydnj commented Oct 21, 2022

Motivation

We're getting reports from Stripe users where VSCode is spitting out scary-looking error messages for innocuous things. Previous versions of the extension seemed to handle these gracefully, but the upgrade to vscode-languageclient seemingly introduces problems.

Let's roll this back.

Test plan

See included automated tests.

@froydnj froydnj requested a review from a team as a code owner October 21, 2022 20:47
@froydnj froydnj requested review from jez and removed request for a team October 21, 2022 20:47
@froydnj froydnj enabled auto-merge (squash) October 21, 2022 20:48
@froydnj froydnj merged commit 6d97fa0 into master Oct 21, 2022
@froydnj froydnj deleted the froydnj-revert-vscode-extension branch October 21, 2022 21:02
damolina-stripe added a commit that referenced this pull request Feb 28, 2025
Upgrade LanguageClient to 8.1.0
- Update code to use `start` instead of `onReady`: this is not a trivial as it sounds as behaviors changed slightly, particularly in regards to error handling.
- Adding `initializationFailedHandler` to the `LanguageClient` created by `createClient` so preexisting connection errors (e.g. `Pending response rejected since connection got disposed`) do not surface as notifications (chane introduced in LC 3.17).
- Wrapping the `LanguageClient` created by `createClient` with an implementation that overrides `error` to override the `force` flag that causes some errors to bubble up.  There were and are ongoing reports about this: 8.0 allowed errors to bubble up which exposed the issues with `force`, and `8.1.0` fix some, but not all issues (and still there as of latest version on 2/28/2025).

Misc:
- Move `SorbetLanguageClient` to `sorbetLanguageClient.ts` to match class name.
- `languageClient.ts`, next to `languageClient.metrics.ts` operate on `LanguageClient`. Conviniently, existing `languageClient.test.ts` matches this separation.

References
- Previous attempt: Revert "update vscode-languageclient with LSP 3.17 support (#6492)" #6501
- Relevant spec changes:
   - `onReady` removed: [3.17.0](https://github.com/microsoft/vscode-languageserver-node/blob/main/README.md#3170-protocol-800-json-rpc-800-client-and-800-server)
   - Updates to error handling (required but not enough to limit spurious errors from  showing as notifications, unless handled) : [3.17.3](https://github.com/microsoft/vscode-languageserver-node/blob/main/README.md#3173-protocol-810-json-rpc-810-client-and-810-server)
damolina-stripe added a commit that referenced this pull request Mar 3, 2025
* Upgrade LanguageClient to 8.1.0

Upgrade LanguageClient to 8.1.0
- Update code to use `start` instead of `onReady`: this is not a trivial as it sounds as behaviors changed slightly, particularly in regards to error handling.
- Adding `initializationFailedHandler` to the `LanguageClient` created by `createClient` so preexisting connection errors (e.g. `Pending response rejected since connection got disposed`) do not surface as notifications (chane introduced in LC 3.17).
- Wrapping the `LanguageClient` created by `createClient` with an implementation that overrides `error` to override the `force` flag that causes some errors to bubble up.  There were and are ongoing reports about this: 8.0 allowed errors to bubble up which exposed the issues with `force`, and `8.1.0` fix some, but not all issues (and still there as of latest version on 2/28/2025).

Misc:
- Move `SorbetLanguageClient` to `sorbetLanguageClient.ts` to match class name.
- `languageClient.ts`, next to `languageClient.metrics.ts` operate on `LanguageClient`. Conviniently, existing `languageClient.test.ts` matches this separation.

References
- Previous attempt: Revert "update vscode-languageclient with LSP 3.17 support (#6492)" #6501
- Relevant spec changes:
   - `onReady` removed: [3.17.0](https://github.com/microsoft/vscode-languageserver-node/blob/main/README.md#3170-protocol-800-json-rpc-800-client-and-800-server)
   - Updates to error handling (required but not enough to limit spurious errors from  showing as notifications, unless handled) : [3.17.3](https://github.com/microsoft/vscode-languageserver-node/blob/main/README.md#3173-protocol-810-json-rpc-810-client-and-810-server)

* Allow DISABLED > INITIALZING transition: we should start in the former state now since initialization does not really start until `start` is invoked.

Set `activeLanguageClient` before `start` because components will query the client for state, in particular, the statusbar item

* Set `RUNNING` after `start` has completed.  Also, to make easier to think about the scenario move setting `INITIALIZING` right before instead of at `startSorbetProcess` (since it is actiona t a distance and even if correct it would have not corresponding `RUNNING`).

* Fix: `initializationFailedHandler` should return `false` since we control retries (otherwise this enters a bad loop of restarts).

Fix: in `start`, only set `RUNNING` if status is still `INITIALIZE`.  When the Sorbet process fails to start, status might be `RESTARTING` or `ERROR` and it is not a valid/correct transition to go to `RUNNING` (even if it gets reset to proper via other events).

* Add punctuation to improve log entry.

* Update CHANGELOG.

- Ship version 0.3.40.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0