error in server REPL after connection drops: `(wrong-number-of-arguments (3 . 3) 4)`

[kleinschmidt]

Occasionally, when I hit Ret in a server REPL after the connection to the server has dropped (port forwarded over SSH), I get the following error (debugger output):

Debugger entered--Lisp error: (wrong-number-of-arguments (3 . 3) 4)
  #f(compiled-function (client req msg) #<bytecode 0x477a0725>)(#<jupyter-repl-client jupyter-repl-client-5990c504> nil "incomplete" "")
  apply(#f(compiled-function (client req msg) #<bytecode 0x477a0725>) #<jupyter-repl-client jupyter-repl-client-5990c504> (nil "incomplete" ""))
  jupyter-handle-is-complete-reply(#<jupyter-repl-client jupyter-repl-client-5990c504> nil "incomplete" "")
  jupyter-repl-ret(nil)
  funcall-interactively(jupyter-repl-ret nil)
  call-interactively(jupyter-repl-ret nil nil)
  command-execute(jupyter-repl-ret)

Once it gets into this state, the only recovery that I've been able to figure out is to kill the REPL buffer and reconnect. That's not ideal because the REPL history is specific to the buffer so it gets lost.

(FWIW, other times when the connection drops, I get a ZMQ websocket closed error instead, and restoring the connection to the server is enough to recover, unlike this case. Because this happens only sporadicaly, I haven't been able to figure out what causes one or the other but I'd appreciate any advice on tracking that down).

This is installed from master (0a7055d) via Straight, emacs version GNU Emacs 27.2 (build 1, aarch64-apple-darwin21.4.0, Carbon Version 165 AppKit 2113.4) of 2022-03-30.

[kleinschmidt]

This seems to be specific to interaction in the REPL buffer itself; when I send code to evaluate with C-c C-z in an associated code buffer, I get a websocket closed error, which triggers a reconnect. Then the REPL works as normal. If instead the first thing I do is hit Enter in the REPL, I get stuck in the state described here; I can still send stuff to evaluate with C-c C-z (once the server connection is restored) but can't interact in the REPL itself.

[pank]

This change to jupyter-repl.el seems to fix the error for me:

diff --git a/jupyter-repl.el.orig b/jupyter-repl.el
index cbc6c6a..3864f68 100644
--- a/jupyter-repl.el.orig
+++ b/jupyter-repl.el
@@ -1197,7 +1197,8 @@ execute the current cell."
                                      "")))
               (jupyter-handle-is-complete-reply
                   jupyter-current-client
-                nil (if complete-p "complete" "incomplete") "")))
+                  nil (list :content (list :status (if complete-p "complete" "incomplete")
+                                           :indent "")))))
            (t
             (let ((res (jupyter-wait-until-received :is-complete-reply
                          (let ((jupyter-inhibit-handlers '(not :is-complete-reply)))

jupyter-handle-is-complete-reply expects a message in a format that jupyter-message-content understands (try (jupyter-with-message-content '(:content (:foo "bar" :baz "ignored")) (foo) foo) => "bar").

(sorry I can't clone the repo ATM)

[gmoutso]

I get his too often. Also with the latest branch that seems to have the change?

[gmoutso]

Just a comment, this commit also complicates things. If the websocket is lost, I can only kill the kernel to get rid of the buffer! Of course, the solution is to just let the stagnant REPL lay about, create a new REPL and jupyter-associate-... with the new REPL.