Support that server can request a restart from the client.

[dbaeumer]

If a server got into an inconsistent state there is little the server can do to recover from this. We should consider to allow server to request:

• a restart
• a rsync of documents
• ...

[mickaelistria]

What about we don't spec it and mention a server that is in inconsistent state just stops and client is expected to restart it when necessary?

[dbaeumer]

I am just adding this to the new Implementation consideration section. However I still think it would make sense to make this explicit.

[mroch]

here's a scenario we're running into with Flow: you can pin your project to a specific version of flow by depending on that version of flow-bin in package.json. when the version changes, the LSP server (flow lsp) exits so that the correct version can be restarted. it turns out that it's pretty easy to check out 5 commits within 3 minutes that jump back and forth across one of these version bump commits (say, rebasing a bunch of branches).

alternatively, maybe the server could exit with a particular exit code, like EX_TEMPFAIL (75):

/*
 *	EX_TEMPFAIL -- temporary failure, indicating something that
 *		is not really an error.  In sendmail, this means
 *		that a mailer (e.g.) could not create a connection,
 *		and the request should be reattempted later.
 */
#define EX_TEMPFAIL	75	/* temp failure; user is invited to retry */

https://github.com/freebsd/freebsd/blob/0e869b7d7edf75ff2ef47f2dbebdabadfb216ff2/include/sysexits.h#L84-L87

[LaurentTreguier]

Another possible use case is updating: if a server updates itself, it most likely will have to be restarted to use the new version.

[Linskeyd]

Are there any updates on the consideration of this proposal? Could a 'restart' request, sent by the server, be considered for 3.16?