Manually re-launching LSP servers

[cccs-jc]

We've noticed that sometimes the sql-language-server (LSP node server) we use stops or dies for some reason.

For example this will happen when putting a laptop to sleep. In this scenario it's not a big deal. We can just restart the jupyter lap process and a new LSP server is also created.

However in a JupyterHub environment it's very inconvenient to have to restart the hosting POD just to force the LSP server to restart.

Is there a way in JupyterLab to force the restart of an LSP server. Is there anything in the UI or on command line that would trigger JupyterLab to start a new LSP instance if it dies.

[JulianSMoore]

Although I would like a better solution, I have found that F5 refresh of the Jupyter tab causes the Python LSP to start working again (Win 10; Google Chrome)

[cccs-jc]

thanks @JulianSMoore I've notice that as well. Since I switch to using a python launch script pressing F5 restarts the LSP server which is better than nothing.

Not sure it did that when I was using a declarative registration of the LSP spec. But it definitely does when using python launch script https://github.com/CybercentreCanada/jupyterlab-sql-editor/blob/main/ipython_magic/sparksql/main.py

[krassowski]

I added this to the 4.0 release plan. If someone wants to work on this, I would propose to add this:

• in the status popover, and/or
• as a command in the command palette ("restart all servers connected to this document").

We already have code for restarting connection:

jupyterlab-lsp/packages/jupyterlab-lsp/src/adapters/adapter.ts

Line 254 in ed88a08

protected reload_connection() {

which is triggered when changing kernels. Restarting connection does not guarantee restarting the LSP server though. We would probably need to add a way to command jupyter-lsp to restart the LSP servers.

[bollwyvl]

Yeah tying into the "running" tab would be ideal... that was one of the nice things about the kernel approach (though you'd just see the one "manager" kernel, not each server). As that ui probably won't be readily accessible in retro/nb7, we'll also need something else... And probably a "big hammer" command, e.g. _Restart all Language Servers_. Further, I'd love to see the ability to propagate individual servers' stderr to a log viewer in lab... Perhaps as another, dedicated websocket. Finally: some of these concerns are shared with jupyter-server-proxy. It's possible we could reuse some API and UI components, even if they have different approaches to many things.