In some cases ZMQChannelsWebsocketConnection.kernel_manager._request_info_future would stuck forever

[linlol]

Description

It could only be reproduced in great lag?

As we all know, once request_kernel_info is called, jupyter server would cache connection's _kernel_info_future to kernel manager and keep reusing as below

https://github.com/jupyter-server/jupyter_server/blob/main/jupyter_server/services/kernels/connection/channels.py#L579

Below corner case could shown up with great network latency (in our case, we have jupyter frotnend running in Singapore and backend running at EU)

1. When open notebook, kernel_info_request is sent with future cached as reused

2. If user clicks restart meanwhile, the request in 1 may possibly never get response.

3. In this case, the restart kernel would keep awaiting the future generated bt step 1, which would never be available till the end of timeout (which is 60s)

Reproduce

Can only be reproduced with great network latency

1. Open notebook in jupyterlab
2. Click restart and run all button before kernel connected

Expected behavior

Context

• Operating System and version: we are using docker with image built on rhel 8, and host server Ubuntu (this corner case could be portable across at least unix-like systems)

• Browser and version: Chrome v138 (shall be irrelevant with front end)

• Jupyter Server version: 2.14.1

Troubleshoot Output

Paste the output from running `jupyter troubleshoot` from the command line here.
You may want to sanitize the paths in the output.

Command Line Output

Paste the output from your command line running `jupyter lab` here, use `--debug` if possible.

Browser Output

Paste the output from your browser Javascript console here, if applicable.

[linlol]

Basically talk about same thing in #1552 this is a follow up analysis

[linlol]

Please advise that

1. Is this a known issue?

2. By any luck can I make some server extension to override the behaviour, and injected thru traitlet

3. Can we build some mechanism to drop the kernel_manager._kernel_info_future if it looks to be corrupted and can never be done

[linlol]

@krassowski @minrk does it make sense to you if I add a callback on future time-out to clear the future await kernel info

[minrk]

It should probably be cleared on timeout, and should probably also be cancelled on restart, so that things don't wait for a previous instance.

[linlol]

thanks @minrk , yes currently we would not wait forever for the kernel_restart, while in this case, every restart would keep waiting the cached self.kernel_manager._kernel_info_future

what I meant is that, (sorry that probably I am wrong) shall we teardoown the self.kernel_manager._kernel_info_future during kernel info timeout