code-sandboxes 1.9.27__tar.gz → 1.9.28__tar.gz

{code_sandboxes-1.9.27 → code_sandboxes-1.9.28}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: code_sandboxes
-Version: 1.9.27
+Version: 1.9.28
 Project-URL: Home, https://github.com/datalayer/code-sandboxes
 Author-email: Datalayer <info@datalayer.io>
 License: BSD 3-Clause License

{code_sandboxes-1.9.27 → code_sandboxes-1.9.28}/code_sandboxes/__version__.py

@@ -3,4 +3,4 @@
 
 """Code Sandboxes."""
 
-__version__ = "1.9.27"
+__version__ = "1.9.28"

{code_sandboxes-1.9.27 → code_sandboxes-1.9.28}/code_sandboxes/jupyter_server_sandbox.py

@@ -650,13 +650,17 @@ class JupyterServerSandbox(Sandbox):
                 "Failed to restart Jupyter kernel: the server answered %s", response.status_code
             )
             return False
-        # The websocket the client holds is to the kernel that has just been
-        # replaced; reconnecting is what makes the next execution land in the
-        # new interpreter rather than on a channel nobody is reading.
-        with contextlib.suppress(Exception):
-            self._client.stop()
-        with contextlib.suppress(Exception):
-            self._client.start()
+        # **The websocket is kept, never reconnected.** jupyter-server binds a
+        # kernel's websocket to the kernel id, not to its process, and moves
+        # it onto the restarted kernel itself — which is how JupyterLab's own
+        # restart works. Reconnecting here broke every restart instead:
+        # `jupyter_kernel_client` caches its shell and IOPub channels bound to
+        # the socket they were built with, so after `stop()` and `start()` the
+        # client held a new socket while its channels still wrote to the
+        # closed one. The next execution answered `ok` with no output — found
+        # on r1, 2026-09-18, as checks 7, 8 and 9 all failing together, and
+        # reproduced against the approved base itself, with the deployed
+        # client. Swallowing both calls' errors is what hid it.
         return True
 
     @marks_execution

{code_sandboxes-1.9.27 → code_sandboxes-1.9.28}/tests/test_jupyter_server.py

@@ -559,6 +559,34 @@ class TestRestartingTheKernelRatherThanTheConnection:
         finally:
             sandbox.stop()
 
+    def test_the_connection_is_kept_across_the_restart(self, monkeypatch):
+        """jupyter-server moves a kernel's websocket onto the restarted kernel.
+
+        Reconnecting broke it: `jupyter_kernel_client`'s channels stay bound
+        to the socket they were built with, so after a `stop()` and `start()`
+        every execution answered `ok` with no output (r1, 2026-09-18).
+        """
+        sandbox = _started_sandbox(monkeypatch, kernel_id="kernel-1")
+        lifecycle: list[str] = []
+        client = sandbox._client
+        monkeypatch.setattr(client, "stop", lambda *a, **k: lifecycle.append("stop"))
+        monkeypatch.setattr(client, "start", lambda *a, **k: lifecycle.append("start"))
+
+        class _Response:
+            ok = True
+            status_code = 200
+
+        monkeypatch.setattr(
+            "code_sandboxes.jupyter_server_sandbox.requests.post",
+            lambda *args, **kwargs: _Response(),
+        )
+        try:
+            assert sandbox.restart_kernel() is True
+            assert lifecycle == []
+            assert sandbox._client is client
+        finally:
+            sandbox.stop()
+
     def test_a_server_that_refuses_the_restart_is_reported_not_raised(self, monkeypatch):
         sandbox = _started_sandbox(monkeypatch, kernel_id="kernel-1")