You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When establishing a new websocket connection to a kernel whose execution is paused due to debugging (e.g. paused on a breakpoint), messages sent over the websocket get no reply -- including debug requests.
Reproduce
Connect to a kernel that supports debugging (e.g. IPyKernel >= 6)
Set a breakpoint in the kernel (e.g. using JupyterLab) and run the code so that execution is paused
Open a new websocket connection to the kernel
Notice that the websocket gets no responses, even from messages over the control channel.
Tested against different versions of jupyter_server and traced the issue back to version 1.1.2 (the issue does not repro in 1.1.1). This correlates with #361. While in this "frozen" state the console also shows that the server is nudging the kernel repeatedly, so it makes sense if this is the cause.
Expected behavior
The kernel should still be able to communicate, at least over the control channel so that frontends can continue the debugger and unblock the shell.
The text was updated successfully, but these errors were encountered:
Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.
You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋
Description
When establishing a new websocket connection to a kernel whose execution is paused due to debugging (e.g. paused on a breakpoint), messages sent over the websocket get no reply -- including debug requests.
Reproduce
control
channel.Seems to be causing jupyterlab/jupyterlab#10174.
Tested against different versions of
jupyter_server
and traced the issue back to version 1.1.2 (the issue does not repro in 1.1.1). This correlates with #361. While in this "frozen" state the console also shows that the server is nudging the kernel repeatedly, so it makes sense if this is the cause.Expected behavior
The kernel should still be able to communicate, at least over the
control
channel so that frontends can continue the debugger and unblock the shell.The text was updated successfully, but these errors were encountered: