Failed to list clusters: might the server extension not be installed/enabled?
rcthomas opened this issue · comments
Quite frequently, we see this message
Dask Server Error
Failed to list clusters: might the server extension not be installed/enabled?
It is spurious because the server extension is indeed installed and enabled. Both dask-core and distributed are installed at version 2022.1.0, and dask-labextension is at 5.2.0.
I've told users they can ignore this, and maybe they need to clear the search field in the dask-labextension interface, since that seemed to work for me.
The error message is trying to be helpful but it's really misdirection 100% of the time it pops up. Users see that and then they go and try to install something themselves sometimes and it doesn't help or makes things worse for them. Something is triggering this message and that condition is being interpreted incorrectly. Is there a way to make this not happen or maybe happen less frequently?
One thing to note is we have a central, shared installation of JupyterLab, but users can run whatever kernel they like (it can come from a conda environment they manage themselves for instance) and we can't guarantee that the version of dask or distributed matches that in the environment JupyterLab runs from. I mention that, and the version match aspect, because I saw #214.
Apart from this issue it works pretty nicely!
Sorry for the extremely slow response @rcthomas. This message was more useful in a pre-JLab 3 world where the frontend piece of the extension had to be installed separately from the backend piece. Now that they are installed together, I think we can relax the check a bit.
Right now we are showing that message after the first failed attempt to talk to the backend. I'm not sure why it is failing in your deployment (probably some race in server startup), but we can probably just show the message after several (say 10?) failures.
Thanks! I think users notice it when they've been idle a long time, like overnight? But other times it seems to pop up seemingly randomly. I haven't noticed it too much recently myself. But yes, if it could maybe pop up only after some number of failures (10 sounds like a good start --- what's the interval between attempts to contact the backend?) that might help.
Thanks for the additional context — if it’s showing the message to users after a long absence, or due to a network hiccup, that sounds a bit different from my idea of a startup race. Maybe we can avoid showing it if there has ever been a successful check. That is to say, if we have successfully talked to the backend once, then any subsequent issue won’t be due to an installation problem.
The startup race you're talking about could be happening, but I haven't had reports like "when I start JupyterLab, I immediately get this message." It's more like "sometimes I'm trucking along, doing stuff, and boom this message pops up."
The change you're suggesting to do the check once and then not worry about it sounds like it's actually more in line with the spirit behind the error message itself. Thanks again!
@rcthomas I've just published version 5.3.0 of this extension which should include a fix for this issue. If you find that is not the case, please let me know and we can reopen!
Thank you, we'll give it a shot!