Refreshing when stopped on a breakpoint

[JohanMabille]

As pointed out by @jtpio in #217, refreshing the page when the code execution is stopped on a breakpoint does not work. The reason is that after refreshing, the client sends a kernel_info_request to the kernel and waits for its reply. This request is sent on the shell, however the thread executing on the shell in xeus_python is stopped because of the previous breakpoint. Therefore, the client never gets its answer and loops on creating web sockets.

We can workaround this issue by restarting the debugger when refreshing the page. This would resume the execution of the thread on the shell without loosing the breakpoints.

A lont-term solution would be to have the kernel_info_request sent on the control instead of having it on the shell but that would require changes in Jupyter Lab core.

cc @afshin @KsavinN

[jtpio]

It's also worth keeping an eye on the kernel and session architecture refactoring work happening in JupyterLab: jupyterlab/jupyterlab#7252

For reference this is where the kernel_info_request message is sent on the control channel:

https://github.com/jupyterlab/jupyterlab/blob/00b17fc573af105044d03ca76d3f9cb07b871992/packages/services/src/kernel/default.ts#L478-L479

[JohanMabille]

It seems that actaully the workaround is not possible since the web socket that allows to communicate with the kernel is not created until a first web socket receives a kernel_info_reply.

Therefore the only mean to fix that is to send the kernel_info_request on the control.

[jtpio]

We discussed another way to detect whether a kernel supports debugging without having to rely on the debug info reply.

One workaround could be to send one of the debug requests, for example debugInfo, and wait for a response (without checking the content).

One possible issue with this is that other kernels such as ipykernel will receive debug_request messages and log a "Unknown message type" warning.

Also we currently use the info promise before sending messages to the kernel here:

debugger/src/session.ts

Line 197 in dc94d28

return this._connection?.kernel?.info;

Instead we could check whether the kernel is available with this._connection?.kernel;

Finally there is an issue about sending the debug_info_request on the control channel: jupyterlab/jupyterlab#7560

[jtpio]

Moving to 0.2.0 to check if this is a viable workaround.

[jtpio]

A manifestation of the same issue, when creating a new console from a notebook for which the execution has stopped: