Jupyter API: A resolved server cannot be used on a notebook which had a server that was removed. NB controller disposed.

[kevineger]

Environment data

• VS Code version: 1.105.0
• Jupyter Extension version (available under the Extensions sidebar): 2025.9.1
• Python Extension version (available under the Extensions sidebar): 2025.16.0
• OS (Windows | Mac | Linux distro) and version: Debian
• Python and/or Anaconda version: N/A
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): N/A
• Jupyter server running: Remote

Repro Steps

This bug report is in extending the Jupyter API. I've implemented a JupyterServerProvider which resolves remote servers.

1. Open a new notebook.
2. Create and resolve a new server from the JupyterServerProvider.
3. Execute a code cell.
4. Remove the server, firing the onDidChangeServers event for the JupyterServerProvider. provideJupyterServers now returns no servers.
5. Observe that the kernel picker disconnects.
6. Create and resolve a new server from the JupyterServerProvider.
7. Execute a code cell.

Expected behaviour

The cell can be executed.

Actual behaviour

Nothing happens. The Notebook controller has been disposed. See logs below.

Investigation notes

• If I don't execute a cell, which creates the session, (step 3 in repro) on the first server that gets removed, the bug doesn't repro.
• Each time I execute a cell on the second server (step 7), Error: Cannot call start again is logged to the extension host output.
• The only workaround is to re-load the file (which reconstructs the NB controller).

Logs

Jupyter

I've uploaded the Jupyter logs: jupyter-output-trace-logs.txt. To facilitate with debugging, I've separated the logs by the actions I took in the repro steps. The markers are:

• ~~~ Start handleCommand to resolve a server
• ~~~ Click on one of the kernels, as returned by the kernelspecs
• ~~~ Successfully execute a cell
• ~~~ Remove a server, which fires the onDidChangeServers event
• ~~~ Resolve the second server
• ~~~ Select a kernel
• ~~~ Execute a cell

Ctrl+f for ~~~ should make jumping between the actions easier than perusing the verbose trace logs. Hope that helps with debugging!

Extension host

Each time the cell is executed on the second server (whose notebook controller is disposed), this message is emitted:

Error: Cannot call start again
    at Object.start (/usr/local/google/home/keger/.vscode-server/cli/servers/Stable-03c265b1adee71ac88f833e065f7bb956b60550a/server/out/vs/workbench/api/node/extensionHostProcess.js:201:28358)
    at iM.start (/usr/local/google/home/keger/.vscode-server/extensions/ms-toolsai.jupyter-2025.9.1-linux-x64/dist/extension.node.js:172:662)
    at /usr/local/google/home/keger/.vscode-server/extensions/ms-toolsai.jupyter-2025.9.1-linux-x64/dist/extension.node.js:309:94823
    at Array.forEach (<anonymous>)
    at n.executeQueuedCells (/usr/local/google/home/keger/.vscode-server/extensions/ms-toolsai.jupyter-2025.9.1-linux-x64/dist/extension.node.js:309:94793)
    at processTicksAndRejections (/usr/local/google/home/keger/src/colab-vscode/lib/internal/process/task_queues.js:105:5)
    at n.handleExecution (/usr/local/google/home/keger/.vscode-server/extensions/ms-toolsai.jupyter-2025.9.1-linux-x64/dist/extension.node.js:309:91402)
    at r4.$executeCells (file:///usr/local/google/home/keger/.vscode-server/cli/servers/Stable-03c265b1adee71ac88f833e065f7bb956b60550a/server/out/vs/workbench/api/node/extensionHostProcess.js:201:24241) {stack: 'Error: Cannot call start again
    at Object.…h/api/node/extensionHostProcess.js:201:24241)', message: 'Cannot call start again'}

[kevineger]

@DonJayamanne - I took a crack at fixing this: #17097.

---

Reading through the logs I've reported, this is my interpretation and starting point for trying to debug through the Jupyter code.

1. Connecting and executing a cell with the first server binds the active session and its controller to the notebook document.
2. Removing the server triggers the cleanup.
3. The core problem: Jupyter sees the server is gone and disposes all associated controllers, including the active one. In the logs, this can be observed at 01:13:38.950 when the JupyterServerProvider fires onDidChangeServers.
4. At that moment, the notebook document is still bound to the disposed controller.
5. When I connect to the second server and select a new kernel (ed9f0d48...) at 01:16:06.898, the kernel picker UI updates but the notebook's internal state does not. It retains its reference to the original, dead controller.
6. Then when a cell execution happens, we see the failure logs both in Jupyter and the extension host. Jupyter tries to createNotebookCellExecution, which fails instantly because the controller is gone. The executeQueuedCells function continues in this bad state and another part of the code improperly calls start on an execution object that's already failed/stopped.

[DonJayamanne]

@kevineger thank you for trying to look into this, and I'm sorry for not having looked into this issue.
A few questions about the steps

• Step 3: I'm assuming this is a long running cell like very long for loop that waits 1 second in each loop (lets assume the cell runs for 1 hour)
• Step 4: I'm assuming when you say remove the server, this means the provider will remove the server and trigger the onDid change event
• Step 5: When this disconnects, what do you mean (please can you share a screen shot), also whats the state of the cell? Has it stopped running
• Step 6: What are the steps in the UI? How do you do this? Do you go through the entire process of picking another server from your provider and that starts a server and its returned and picked
• Step 7: At this point, I'm assuming that the cell stopped running in step 5 & thats why you're able to run this cell

[kevineger]

Step 3: I'm assuming this is a long running cell like very long for loop that waits 1 second in each loop (lets assume the cell runs for 1 hour)

Nope, any execution (to create the kernel session).

Step 4: I'm assuming when you say remove the server, this means the provider will remove the server and trigger the onDid change event

Correct.

Step 5: When this disconnects, what do you mean (please can you share a screen shot), also whats the state of the cell? Has it stopped running

After the onDidChangeServers event fires and the subsequent provideJupyterServers call no longer returns it, the kernel picker switches back to its default Select Kernel state.

Step 6: What are the steps in the UI? How do you do this? Do you go through the entire process of picking another server from your provider and that starts a server and its returned and picked

Click kernel picker and through a command, resolve a new server.

Step 7: At this point, I'm assuming that the cell stopped running in step 5 & thats why you're able to run this cell

The cell from step 5 can just be an immediately executed print("hi"). Here I'm re-running the cell against the new server/kernel/session.

---

Give me 5 minutes and I'll attach a video of the full repro (need to switch computers).

[kevineger]

@DonJayamanne, find attached a video showing the repro. Let me know if any of it is unclear. In it I create two different servers which get resolved (with different IDs).

NB.controller.disposed.repro.webm

I left a few notes on the PR I opened, happy to chat there or here.

[kevineger]

By the way, this repros without 3rd party JupyterServerProvider-s.

Repro Steps:

1. Run a Jupyter server.
2. Create an empty notebook.
3. Click Select Kernel > Existing Jupyter Server... > Enter the localhost addrress.
4. Execute a cell (e.g. print("foo")).
5. Click the kernel selector > Select Another Kernel... > Existing Jupyter Server... and delete the entry from step 3.
6. Re-add the Existing Jupyter Server... and select it.
7. Execute a cell (e.g. print("foo")).

Expected: cell runs
Actual: same controller disposed error as described.

Find attached a video of the above repro.

Local.remote.server.webm

[kevineger]

Hey @DonJayamanne just checking in, let me know if there's any additional info I can provide. I did update the linked PR, happy to make whatever changes are needed there.