VS Code doesn't call shutdown when exiting the standard client

Environment

Operating System: any
JDK version: any
Visual Studio Code version: 1.67.2, code-insiders
Java extension version: 1.6.0

Steps To Reproduce

open a java project with VS Code
stop it
check the standard server log

Current Result

shutdown is not called

Expected Result

shutdown should be called

How did this regress ?

How did this regress ?

See https://github.com/Microsoft/vscode-languageserver-node/blob/main/README.md#3170-protocol-800-json-rpc-800-client-and-800-server

cleanup of client start and stop methods. Both methods now return a promise since these methods are async. This is a breaking change since start returned a disposable before. Extensions should now implement a deactivate function in their extension main file and correctly return the stop promise from the deactivate call. As a consequence the onReady() got removed since extensions can await the start() call (even multiple times).

This change is included to vscode-languageclient 7.1.0-next.5 - https://github.com/microsoft/vscode-languageserver-node/blob/release/client/7.1.0-next.5/client/src/common/client.ts#L3335

We've been using 7.1.0-next.5 for some time now (83eff21#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519). I almost couldn't believe this regressed in 0.82.0, so I just tested our 1.6.0 release and it shuts everything down as expected immediately. If this change fixes things, I'm fine with merging, but am just curious at the cause of this.

so I just tested our 1.6.0 release and it shuts everything down as expected immediately.

Could you attach your standard server log?

VS Code 1.6.0

shutdown is not called; Java LS doesn't save the workspace

With the PR:

shutdown is called; Java LS saves the workspace

I have tested VS Code Java 1.3.0, 1.4.0, 1.5.0 and 1.6.0, VS Code 1.67.2, VS Code Insiders, VS Code 1.65.0, VS Code 1.63.0 All these versions have this issue.
It is possible that the problem has been introduced by the newer VS Code.

I'm able to reproduce. It's an issue. I'm not yet sure why, but if I have the MicroProfile extension installed as well, which also happens to start up, then on shutdown, the Java extension also shuts down with it. However, on its own, the Java extension remains up :\

@snjeza

@snjeza , I just tried October 2021 (version 1.62.3) + redhat.java 1.4.0. Can you confirm that worked ?

I just tried October 2021 (version 1.62.3) + redhat.java 1.4.0. Can you confirm that worked ?

Yes, I can.

@snjeza

cleanup of client start and stop methods. Both methods now return a promise since these methods are async. This is a breaking change since start returned a disposable before. Extensions should now implement a deactivate function in their extension main file and correctly return the stop promise from the deactivate call. As a consequence the onReady() got removed since extensions can await the start() call (even multiple times).

@snjeza Nice catch! thanks. This might mitigate the issue microsoft/vscode-java-pack#954 as well.

Starting from LanguageClient@8.0.1, the BaseLanguageClient.start() has been changed to return a promise instead of Dispose, and onReady() is removed, they're breaking changes to vscode-java.

https://github.com/microsoft/vscode-languageserver-node/blob/release/client/8.0.1/client/src/common/client.ts#L933

We need to make changes to the client code in vscode-java to support the new behavior. Created an issue #2474 to track the future changes.

vscode-java/src/standardLanguageClient.ts

Line 105 in 97b29fa

this.languageClient.onReady().then(() => {

Just one thing. We aren't running vscode-languageclient 8.0.1. We're still on 7.1.0-next.5. So how does that change affect us now. Did the VS Code platform change something about the extension API after 1.62.3 ?

On a side note, relying on parent process watcher to kill the LS might be the cause of many corrupted workspaces (especially in bigger projects) so fixing things like this could yield a lot of benefit.

Just one thing. We aren't running vscode-languageclient 8.0.1. We're still on 7.1.0-next.5. So how does that change affect us now. Did the VS Code platform change something about the extension API after 1.62.3 ?

On a side note, relying on parent process watcher to kill the LS might be the cause of many corrupted workspaces (especially in bigger projects) so fixing things like this could yield a lot of benefit.

The stop method change doesn't change any LSP feature behavior, I don't think VS Code platform has updated its extension API for this. The language client is owned by each extension, and its start() and stop() is called by extension itself. If vscode-java stays at 7.1.0-next.5, we don't need to deal with start() breaking now.

I remember we had an idea to call SaveManager manually when we shutdown language server, this might help save the state in time.

Navigation Menu

Repository navigation

VS Code doesn't call shutdown when exiting the standard client #2471

Environment

Steps To Reproduce

Current Result

Expected Result

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

VS Code doesn't call shutdown when exiting the standard client #2471

Description

Environment

Steps To Reproduce

Current Result

Expected Result

Activity

rgrunber commented on May 26, 2022

snjeza commented on May 26, 2022

rgrunber commented on May 26, 2022

snjeza commented on May 26, 2022

snjeza commented on May 26, 2022

snjeza commented on May 26, 2022

snjeza commented on May 26, 2022

rgrunber commented on May 26, 2022

rgrunber commented on May 26, 2022

snjeza commented on May 27, 2022

testforstephen commented on May 27, 2022

rgrunber commented on May 27, 2022

testforstephen commented on May 29, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions