Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
kleinschmidt opened this issue Apr 20, 2022 · 4 comments · May be fixed by #421
Open

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

kleinschmidt opened this issue Apr 20, 2022 · 4 comments · May be fixed by #421

Comments

@kleinschmidt
Copy link

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
Copy link
Author

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
Copy link

pank commented Jun 3, 2022

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)

kleinschmidt added a commit to kleinschmidt/emacs-jupyter that referenced this issue Nov 28, 2022
@kleinschmidt
patch from @pank
b8f22fb 
emacs-jupyter#395 (comment)
@kleinschmidt kleinschmidt linked a pull request Nov 28, 2022 that will close this issue
Open
@gmoutso
Copy link

gmoutso commented Jan 22, 2024 •
edited
Loading

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

@gmoutso
Copy link

gmoutso commented Jan 22, 2024 •
edited
Loading

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix for #395 kleinschmidt/emacs-jupyter
3 participants
@kleinschmidt @pank @gmoutso