Navigating in the JupyterLab UI can prevent idle kernels from being culled.

[ojarjur]

Description

When a Jupyter server is configured to cull idle kernels that have connections, the JupyterLab interactions with the Jupyter server can prevent this culling from actually happening.

The simplest such case is when the user navigates between different tabs within JupyterLab, but I've also seen this when refreshing the browser tab that the JupyterLab UI is in.

The root issue seems to be an unexpected interaction between the behavior of the JupyterLab UI and the behavior of the kernel activity tracking.

Specifically, the JupyterLab UI will (on certain events) send a debug_request on the control channel to the running kernel, which results in both a debug_reply on the control channel from the kernel and multiple (in my case I keep seeing two of them) status messages from the kernel on the iopub channel.

This causes issues because it seems that the server will update the kernel's last_activity timestamp on all IOPub messages rather than just execute_input/execute_result messages

That, in turn, prevents the kernel from being considered idle, which then prevents it from being culled.

I am very surprised to see that status messages update the last_activity timestamp. I would have expected those to be no-ops from the standpoint of activity tracking.

Reproduce

1. Set the following config options (either in a config file or on the jupyter lab ... command line):

   1. MappingKernelManager.cull_idle_timeout = 900
   2. MappingKernelManager.cull_connected = True
   3. MappingKernelManager.cull_interval = 10

2. Open the JupyterLab UI, open a new notebook, then close the JupyterLab UI and instead open the .../api/kernels page in your browser.

3. After 15 minutes refresh the .../api/kernels page and see that the idle kernel has been culled.

4. Then re-open the JupyterLab UI, open a new notebook, and then open a new launcher tab at the same time.

5. Without ever executing anything in the notebook, switch between the two tabs in JupyterLab once every minute.

6. Note that the kernel is never culled.

7. Open the .../api/kernels page and note how every time you switch tabs the last_activity timestamp of the kernel is updated.

Expected behavior

I would expect the last_activity timestamp to not be updated due to the status messages sent by the kernel.

Context

• Operating System and version: Debian 13
• Browser and version: Chrome 118
• Jupyter Server version: 2.9.1 (JupyterLab version 4.0.7)