When a server is already running, permalinks take users to the running server instead of the spawn options page

[sunu]

Context

When a user generates a permalink from fancy profiles launcher, sharing and opening that link is expected to take the recipient back to the launcher/options page with the same selection pre-filled.

This works as expected when the user has no server running. But when a server is already running, permalinks take users to the running server instead of the spawn options page, ignoring the config encoded in the permalink entirely.

Steps to reproduce

• Start a server with any default option.
• Once running, open a permalink generated for a different, custom image selection.
• Observe: instead of landing on the spawn options page with that custom image pre-selected, the user is redirected into their already-running server.
• Stopping the server first and then opening the same permalink works correctly, it lands on the spawn options page as expected.

This appears to be standard JupyterHub behavior rather than something specific to fancy-profiles: hitting hub/spawn while a server is already running redirects to that running server by default, unless the user explicitly navigates to /hub/home or uses a custom name for the server like /hub/spawn/<user>/<server-name>. Permalinks are getting caught by this same default redirect.

Proposal

One possible solution could be to make sure permalinks include a custom name (either auto-generated from the image and resource config used or user given) to bypass this limitation?

Updates and actions

No response

[sunu]

I think this also relates to @yuvipanda's comment in jupyterhub/jupyterhub#5101 (comment) because ideally what we want is a way to customize SpawnHandler's behavior to fit our needs here.

[yuvipanda]

I think this is essential complexity (rather than accidental) when you are using the 'default' server (one with blank name). If the server is already running, the options when the user clicks the link are:

1. Show the running server (current option)
2. Stop the running server, and show the form again (also bad!)

The way out of this is to use named servers, so each permalink can have its own server. But how do you choose the name? And how do you handle clashes of the name? If the user clicks the same URL twice, if it has the same name, you're back in this behavior again.

We had the same problem with JupyterLab workspaces a while back, and the solution was to add a feature to JupyterLab to autogenerate them! jupyterlab/jupyterlab#5950

So let's implement a similar solution here, in JupyterHub, that autogenerates new server names? That will allow us to make links that will consistently show the form each time they are clicked.

It does mean you'll have some running servers, but the idle culler can take care of them.

[sunu]

Made an upstream issue for this jupyterhub/jupyterhub#5459