Opening a notebook on remote, closing it, and reopening it does not reuse the same kernel

[rchiodo]

Switch to remote jupyter.
Make some cells like so:

a = 1

print(a)

Run all cells
Close notebook
Reopen.
Run JUST second cell.

It should print A = 1.
It doesn't open the same kernel.

There's a test we had that was supposed to verify this but it was artificially forcing the right kernel to be selected.

[zpincus]

Aah, I was about to open a bug on this myself! Glad I checked first to see if there already was one. This matter came up here a while ago: #1378 (comment) but I failed to look into filing the bug until now. Sorry!

I should note that this bug is actually a significant quality-of-life issue for those of us who have to use remote jupyter to work around the fact that the local jupyter server kills sessions when reloading the vscode UI. (e.g. #1654 -- as a reminder, though reloading the UI may be an uncommon event when people are developing code locally, it gets forced pretty much daily or more when using the vscode-remote ssh extension; if there's ever even a brief hiccup in the ssh reconnection after e.g. wake-from-sleep, a UI reload gets forced, and your local notebook sessions are trashed...)

But this current issue means that every time a reload happens, the notebook gets disconnected from its kernel anyway, even with a remote jupyter server! Which again makes it pretty much impossible to use vscode-jupyter with vscode-remote over ssh. Fortunately, there is a workaround: as I noted above in that comment, it turns out that the notebook will remember its kernel, but only after you manually select it from a list of existing kernels. So you can actually extend the repro steps:

1. Switch to remote jupyter.
2. Make some cells like so:

a = 1

print(a)

3. Run all cells.
4. Close notebook and reopen, or just reload the UI via the "reload" command.
5. Run JUST second cell.
   It should print 1, but it doesn't, because vscode doesn't open the same kernel. (You can verify this by going to the web page for the remote jupyter server and clicking on the "running" tab -- there will now be two running kernels listed: the one that got originally started in step 3, and the one that got started in step 5.)
6. Click on the "select kernel" button in the vscode UI, and select the existing kernel listed. (vscode will hide the kernel it just started up from the list, but will at this point show the original kernel that got started in step 3)
7. Close and reopen the notebook, or reload the UI.
8. Run just the second cell again. It works! The existing kernel is now remembered subsequently.

Unfortunately, there's no way to do this without leaking a kernel into the notebook server (shades of #5862 -- these stray kernels build up fast). Moreover, if you have a few kernels running (or a bunch of kernels that vscode has leaked on your jupyter server) it's also can be quite unclear which kernel is the right one to reconnect to.

Also note that it doesn't help if after step 3 above you click the "select kernel" button and try to manually select the current kernel. You need to select a distinct kernel from the current one before it gets properly associated with the notebook.

Last: it is probably a closely related issue that if you run some code in a newly-created "Untitled" notebook on a remote jupyter server and then save the notebook, trying to run any code again will prompt you to choose a kernel because vscode never really properly associated the notebook with the kernel session that it started up. (At least in this case, you can see the kernel that got started in the kernel selection dropdown menu, though oddly it is listed as having "1 connection" despite vscode not actually being connected to it anymore...)

[zpincus]

Oh no! I just updated to version v2021.10.1001414422 of the Jupyter extension, and the UI changes around the kernel picker now make this issue almost impossible to work around.

Previously, the picker would show the name of each running Jupyter session in the UI, so you could tell which was likely to be the one you wanted to reconnect to (e.g. for my_notebook.ipynb you'd probably want to reconnect to an autogenerated session my_notebook-xxxx-xxxx-xxxx-xxxx for whatever value xxxxs were the autogenerated name for the session.

This was already a bit of a pain given the kernel-leaking issue above means that you typically get two or three of these for any given open notebook. But now there's just a list of anonymous sessions (see screenshot); if you have a few going in a remote server, good luck guessing which is the one you wanted if the "suggested" one isn't right.

[traeki]

Yeah, this one bites me often enough to be a pain. Thanks for filing!

[rchiodo]

What if we:

• On subsequent open of a notebook, check if was remote before
• If remote before, use the '_notebook.selectKernel' command to force it to the original 'remote' session.