Problem with the hub's view of running servers in one little tiny specific case

[rcthomas]

For longer poll intervals, the hub's perception of what notebooks are running can get out of sync with reality for a while that can lead to confusion on the part of the user. Here's a case that's started to come up for us.

A user's notebook dies for some reason, and JupyterLab can now notice this and suggest a redirect to the spawn handler on the hub. We've got a long poll interval (couple minutes) and if you click that button but a poll() hasn't yet been run to update the state, CHP sends you to a 503 page. Makes sense to me but users don't get what it means.

If the user simply waits for a poll() to go by then they can get going again. We've thought of a couple things we could do:

• Customize the CHP 503 page to at least explain to users how they got there and tell them not to panic, just wait and everything will be fine. Bare minimum we could do I think.
• We'll work on solving the problem behind why we have the long polls using a reflector service that can aggregate all the poll data in some way, but that can still suffer delay depending on what we're querying to populate that service.

The main question we have is, could we have the SpawnHandler actually trigger a poll say around here to confirm it's running before trying a redirect to the notebook?

[betatim]

It sounds reasonable to run a poll where you suggest. Is the spawn handler page visited a lot? I think no.

One potential downside is that it might take a "long time" for poll to complete and the page won't render until it is done.