Lag caused by kernel fetch timing out

[noahsalvi]

Context
Over the past few days, my VS Code has begun to hang-up unexpectedly. It happens like every minute and is noticeable when I'm editing a cell. The key strokes I enter are presumably buffered and only entered after the lag has resolved.

Problem
I've used the Jupyter output to pinpoint any abnormalities and found that at the moment where this hang-up occurred, an error was thrown.

09:10:52.100 [info] Execution of code ms-toolsai.jupyter-166 completed in 6ms
09:10:52.580 [error] Error fetching kernels from <URL>: [FetchError: request to <URL> failed, reason: connect ETIMEDOUT 147.87.124.14:59160
	at ClientRequest.<anonymous> (~/.vscode/extensions/ms-toolsai.jupyter-2024.3.1-darwin-arm64/dist/node_modules/node-fetch.js:1:306479)
	at ClientRequest.emit (node:events:529:35)
	at Socket.socketErrorListener (node:_http_client:501:9)
	at Socket.emit (node:events:517:28)
	at emitErrorNT (node:internal/streams/destroy:151:8)
	at emitErrorCloseNT (node:internal/streams/destroy:116:3)
	at process.processTicksAndRejections (node:internal/process/task_queues:82:21)]
09:10:52.580 [error] UniversalRemoteKernelFinder: Failed to get kernels without cache [FetchError: request to <URL> failed, reason: connect ETIMEDOUT <IP:PORT>
	at ClientRequest.<anonymous> (~/.vscode/extensions/ms-toolsai.jupyter-2024.3.1-darwin-arm64/dist/node_modules/node-fetch.js:1:306479)
	at ClientRequest.emit (node:events:529:35)
	at Socket.socketErrorListener (node:_http_client:501:9)
	at Socket.emit (node:events:517:28)
	at emitErrorNT (node:internal/streams/destroy:151:8)
	at emitErrorCloseNT (node:internal/streams/destroy:116:3)
	at process.processTicksAndRejections (node:internal/process/task_queues:82:21)]
09:12:00.472 [info] Execution of code ms-toolsai.jupyter-167 completed in 9ms

First of all, I'm confused about why the fetch for the kernels is made. I only had one notebook open that already uses a local Python environment as its kernel, so fetching wouldn't be necessary? Additionally, the remote kernel in question is not available due to it being only accessible when I'm on the same network, meaning its failure is inevitable. Thus, it wouldn't make sense to simply remove it from my Jupyter kernels.

Is this behaviour expected? Any solutions, or is this a potential bug?

[DonJayamanne]

Thanks for posting this question

Is this behaviour expected?

Yes this is expected.

Thus, it wouldn't make sense to simply remove it from my Jupyter kernels.

If its added to the list, then there's the potential for users to try and run cells against these kernels.
& then we'd need to handle this situation and display appropriate messages and fail gracefully.
Its easier to not display these kernels.

Any solutions,

My suggestion would be to connect to the relevant network, and then try to use the kernels.

[noahsalvi]

I see, thank you.

Sadly, the kernel is on a shared resource, so I'm not always connected to the relevant network.
I guess I'll just remove it and add it back when needed.