Add a way for the server to notify the client that it is shutting down

[smarter]

Suppose that the server encounters a fatal error, if it simply exits, the client has no information on whether it makes sense to restart the server or not so has to resort to heuristics (e.g. for vscode-languageclient: "The default strategy restart the server unless it crashed 5 times or more in the last 3 minutes."). But in many situations, the server may know whether a restart might help or not, and could communicate this to the client, the closest we have in the protocol currently is:

interface InitializeError {
	/**
	 * Indicates whether the client execute the following retry logic:
	 * (1) show the message provided by the ResponseError to the user
	 * (2) user selects retry or cancel
	 * (3) if user selected retry the initialize method is sent again.
	 */
	retry: boolean;
}

But this can only be used in response to initialize, whereas errors could happen at any point.

[ljw1004]

I encountered exactly this situation. For my language (Hack) there are many circumstances where the server might intentionally shut down, e.g. because the project file got updated and the language server has to restart to re-read the project file. Or because the user deliberately ran a command-line tool which shuts down and restarts the language server. In both cases the VSCode "retry up to five times" behavior was incorrect. And I implemented exactly what you describe.

But then I undid my work because I think it was the wrong approach. Instead:

• My LSP server works with the existing straightforward VSCode rule "restart unless it crashed 5 times or more".
• If my server encounters a state where a restart won't help, then it doesn't actually crash/terminate/exit. Instead it stays connected to VSCode, optionally uses showMessageRequest to communicate to the user what's happened, and just responds to all LSP queries with RequestCancelled error.
• If my server genuinely needs to restart but it shouldn't count as a "crash" for purposes of counting how many crashes in 5 minutes, then again it doesn't crash/terminate/exit. Instead it stays connected to VSCode, and just does its restart internally. While it's in the process of restarting (which might take some time), it queues up all didOpen/didChange/didEdit events, and responds to other requests with RequestCancelled.

This has actually delivered for me a more graceful end-user experience, and I'm happier with the code.

I think you should spell out in more precise detail, @smarter, the concrete scenarios you imagine. That way we can evaluate whether they are all adequately addressed by the approach I described.

[smarter]

Thanks for the comment! The solution you describe in case of fatal issues ("stays connected to VSCode, optionally uses showMessageRequest to communicate to the user what's happened, and just responds to all LSP queries with RequestCancelled error.") should work for me and I may end up implementing it, but it feels like a workaround. It seems like something that should be handled by the protocol instead of reimplemented by every LSP server.

[ljw1004]

We have a choice between re-implementing on every LSP server that needs this kind of thing, vs re-implementing on every single LSP client... :)

[dbaeumer]

I have sympathy with both views. Adding something to the protocol that the server can signal it will exist and doesn't want to be restarted feels something useful.

However the case of a 'forced' restart should better be handled by the server restarting internally.