Closed senfbrot closed 3 years ago
Thank you @senfbrot for filling in this issue, detailed feedback like this is always helpful. I see a few issues here:
The logic in:
requires rewriting to include an earlier a query to check if there is a server associated with the language for each document, using like this:
python-language-server
- it is known to be slow, but I never seen it to take so long to start up); would you be willing to experiment a bit and try to configure jedi-language-server
instead and see if it is faster?If we decide to to that, we would probably want to:
until_ready()
is a callback to an interval modifier that could be used to implement this (by default not modifying anything); max_retrials would net to be set to -1
to allow it to continue indefinitely:Do you think that it would be reasonable solution? Would you like to try to create a pull request to add an interval modifier as described in (B)?
An alternative would be to modify the code so that we get a promise / signal for connection.turnedReady
instead, which might be a better solution.
Regardless, I am slightly worried about allowing it to go indefinitely as it would be difficult for the user to find out what has stalled. Here you had a useful message in the browser console; maybe we should just have two awaits (with a timeout), first as-is (maybe taking slightly longer) and the other one coupled with console.warn
and indefinite.
Thank you for the investigation and detailed response. Would it be an option to somehow trigger the start of python-language-server
at an earlier stage, in order to be ready when a notebook is created the first time?
It would be difficult as we do not know what language will the notebook use prior to its opening; starting all language servers available (some users may have all 10 language servers installed) could be seen as a significant waste of resources.
@senfbrot would you be able to check if the new version 3.1 with an additional extra 5-minute timeout solves your problem, please? Of note, it requires JupyterLab 3.0
@krassowski would it be possible to include this in the 2.x line as well? In the current setup I have, the update to JupyterLab 3.0 fails. Anaconda is caught in an endless try to resolve dependencies :-(
Description
When I start JupyterLab for the first time after a fresh installation and create a new notebook, then LSP fails to start properly. In the Browser console it shows that it could not connect:
When I then reload the page, everything works.
Reproduce
Expected behavior
No timeout, LSP working without manual Browser refresh
Context
Required: installed server extensions
Required: installed lab extensions
Troubleshoot Output
Command Line Output
Browser Output (recommended for all interface issues)