Kernel's execution state is not updated after the kernel is crashed while executing code about jupyter_server

[skukhtichev]

There is a ´start_watching_activity´ in jupyter server's MappingKernelManager that listens on iopub channels and updates a kernel state and tracks last activity timestamp. When the kernel crashes jupyter_client restarts the kernel (https://github.com/jupyter/jupyter_client/blob/main/jupyter_client/ioloop/restarter.py#L52). So the kernel has the same id after it is restarted and has idle state.

When the kernel crashes with opened Notebook 7/JupyterLab UI the state is updated correctly on the server, but when the kernel process dies when UI is closed then the execution state is always shown as ´busy´.

Incorrect state could also impact on kernel culling logic because and execution state is monitored in https://github.com/jupyter-server/jupyter_server/blob/main/jupyter_server/services/kernels/kernelmanager.py#L664

[krassowski]

Maybe #990 could solve this?

[krassowski]

FWIW JupyterLab is able to work around this condition (although it is not pretty):

• jupyterlab/jupyterlab#15285
• jupyterlab/jupyterlab#13832

My thinking earlier was that kernel simply cannot send a message when it dies because it is dead, but indeed a kernel manager might be able to handle it. I guess the state should not be idle though.

PS. What is kernel activity monitor? Is it related to https://github.com/jupyter-server/jupyter-resource-usage?

[Wh1isper]

My idea of a so-called monitor may coincide with the idea of a server side execution like jupyterlab/jupyterlab#15448

When we can execute cell with a single command and move document changes to the backend, we can implement a process like jupyterlab/jupyterlab#12455 (Not entirely dependent on the kernel itself, but on its Manager)