Choosing/changing remote local servers is buggy and confusing.

[greazer]

Prep

• Start a jupyter server (ala run jupyter notebook)
• Start VS Code Insiders (I used build from 6/7/2022 and corresponding Jupyter extension)
• Create a new notebook
• Select a local kernel and run a simple cell

Bug 1

• Run Jupyter: Specify Jupyter server for connections
• Choose the server you created in the prep.
• Press enter

I'm still connected to my local kernel. I expected to have to choose a new kernel.

Bug 2

• Run Notebook: Select notebook kernel

The suggested kernel will be the local kernel I'm already connected to. I expect to either have no suggestion, or a suggestion from the server I just connected to.

Bug 3

• Choose one of the server's kernels, run a cell. All seems well.
• Run Notebook: Select notebook kernel You'll still see the local kernel suggested. Probably a dupe of Bug 2, but still.
• Select the local kernel and run a cell.

You'll run against the local kernel, yet the status bar says you're connected to a Remote Jupyter server. Highly confusing.

Bug 4

• Choose one of the server kernels again.
• Ctrl+C the Jupyter server started in Prep.
• Run a cell in VS Code (which is still "connected" to the dead server)

Cell "executes" indefinitely and I can't interrupt it.

I'm forced to reload.

[JakeColor]

Having similar issues recently on my Linux workstation:

1. Spin up a server within a Docker container; confirm a kernel has also been started
2. update "Specify Jupyter remote server for connections" within VS Code
3. go to "select kernel" but no remote kernel is listed

Clues:

• My problem seems similar to https://github.com/microsoft/vscode-jupyter/issues/6653.
• opening the localhost url for the server in a browser works fine (but i'd really like to work in VSC!)
• following the same recipe above on my Macbook works, i.e. the remote kernel is available w/in VSC
• i see the following logs from my jupyter server (in Docker):

  [W 2022-06-08 12:46:40.543 LabApp] Could not determine jupyterlab build status without nodejs
  [I 2022-06-08 12:46:45.853 ServerApp] Writing notebook-signing key to /home/app_user/.local/share/jupyter/notebook_secret
  [W 2022-06-08 12:46:45.855 ServerApp] Notebook {my_notebook}.ipynb is not trusted
  [I 2022-06-08 12:46:46.406 ServerApp] Kernel started: 36b69019-bb2d-45eb-80e4-798b8cc4426a
  [I 2022-06-08 12:46:46.866 ServerApp] Starting buffering for 36b69019-bb2d-45eb-80e4-798b8cc4426a:1660cc72-10b0-445a-b13d-f21c5c9a6128
  [IPKernelApp] ERROR | No such comm target registered: jupyter.widget.control
  [IPKernelApp] WARNING | No such comm: 08bb58c7-34a1-4c21-9360-152e941aba63
  ...

[amunger]

@JakeColor - I created a separate issue from your comment since you're not seeing the kernel at all, whereas the OP is just not having the remote kernel suggested, but it's still in the list.

[minsa110]

RE: Bug 1 -- I have the same issue / confusion.

It says on the status bar (blue circle) that I'm connected to a remote Jupyter server, but it shows in the kernel picker (red circle) that I'm still connected to the local kernel.

RE: Bug 2 -- also +1. In addition, the notebook's path is relative to where I started the kernel, but the file explorer shows my local file system, which makes it more confusing. For example, the Jupyter remote kernel I started was from the top node (see output for os.getcwd()), so to access my data, I have to do pd.read_csv('./data/housing.csv') instead of pd.read_csv('../data/housing.csv') which feels natural / right because of what's shown on the explorer.

+1 on bug 3 & 4 as well. Def agreed that we need a better experience here...

[binderjoe]

This general issue is exacerbated when using Codespaces. Specifically, if you are connected to a Codespace running Jupyter server, the VS Code UI is confusing for two reasons:

1. The kernel picker doesn't differentiate between kernels running locally versus in the codespace.
2. The status bar denotes that the server is "local" when it is running in the codespace. While this is a different form of "remote" than what's reflected in the status bar, it's super confusing because conceptually the server is remote.

[rchiodo]

@binderjoe I don't think the 'local' vs 'remote' problem is going to go away for codespaces. Remote is too overloaded a term.

We should create a separate issue to handle that issue specifically. Same thing happens when in a remote ssh scenario.

[rchiodo]

Created a separate issue for the codespaces issue: https://github.com/microsoft/vscode-jupyter/issues/10601

[rchiodo]

@minsa110 your remote file system not being the same as your local file system is a different issue. I believe this one would address that: https://github.com/microsoft/vscode-jupyter/issues/1366

[connor4312]

I verified bugs 1-4 are present on seemingly the latest of things and on prerelease versions of Python and Jupyter

• VS Code 1.70.0-insider, cc098faebd320a2eea3da6ae154b7e2e1347a4b9
• Python v2022.11.12081004
• Jupyter v2022.7.1002101047

Let me know if there's additional steps needed to see the fixes

[rchiodo]

Sorry there's a setting. Added after the initial submission.

  "jupyter.showOnlyOneTypeOfKernel": true,

This setting was tested with test plan item #10911 though. I don't think this issue can really be verified because it's subjective.

[connor4312]

Thanks, that seems to remove bugs 1-3. However I can still reproduce bug 4 with that setting present.

[rchiodo]

Bug 4 is actually covered by an existing issue: https://github.com/microsoft/vscode-jupyter/issues/10568