Error in console after update 0.8.7->1.0.0

[smee]

Backend uses 1.0.0, Chrome extension was updated, also on 1.0.0. System is Ubuntu 16.04

After opening the browser I see this message in the console:

Dirac v1.0.0, Chrome/57.0.2979.0, Linux/?, Backend API/external/456, Backend CSS/external/415

An error was logged into the internal DevTools console:
:
  * function $dirac$lib$ws_client$unserialize_message$$($unserialized_msg$$){try{return $cljs$reader$read_string$$($unserialized_msg$$)}catch($e42374$$){return console.error([$cljs$core$str$$($cljs$core$get_in$cljs$0core$0IFn$0_invoke$0arity$02$$([$cljs$core$str$$("Unable to unserialize message: "),$cljs$core$str$$($e42374$$),$cljs$core$str$$("\n")].join(""),new $cljs$core$PersistentVector$$(null,2,5,$cljs$core$PersistentVector$EMPTY_NODE$$,[$cljs$core$cst$0kw$0options$$,$cljs$core$cst$0kw$0name$$],null))),$cljs$core$str$$(":")].join(""),$dirac$lib$ws_client$unserialize_message$$),null}}

__

[darwin]

Do you use any other nREPL middleware except Dirac and the default ones?

This looks like something sent a message to Dirac nREPL client and Dirac was unable to unserialise it (e.g. the EDN contained Clojure-specific stuff incompatible with ClojureScript).

I wonder why is this message so cryptic without proper description. Normally you should see a textual error message and proper call stack.

Also this might be related to #43 and #45.

[smee]

I use Dirac and binaryage/devtoools as explicit middlewares, but emacs CIDER might inject something, not sure about that.

Snippet from project.clj:

:profiles {:dev {:jvm-opts ["-Xmx2g" "-XX:+UseCompressedOops" "-XX:+UseG1GC"]
                   :source-paths ["env/dev/clj" "src/cljs" "env/dev/cljs"]
                   :repl-options {:init (do
                                          (require 'web-ui.repl)
                                          (web-ui.repl/start-server))
                                  :nrepl-middleware [dirac.nrepl/middleware]
                                  :port 7002
                                  :host "localhost"
                                  :timeout 1200000}
                   :dependencies [[ring/ring-devel "1.5.1"]
                                  [hawk "0.2.11"] ;; figwheel uses 0.2.10, let's override
                                  [figwheel-sidecar "0.5.8"]
                                  [binaryage/devtools "0.8.3"] 
                                  [binaryage/dirac "1.0.0"]]
                   :env {:dev "true"
                         :db-name "abc-db"
                         :database-url "mysql://......"
                         :input-folder "/home/......."
                         :import-folder "/tmp"}}

and then in web-ui.repl I start the http server, figwheel and dirac:

(ns web-ui.repl
  (:require web-ui.handler
            dirac.agent
            [org.httpkit.server :refer [run-server]]
            [figwheel-sidecar.system :as fw]))

;;;; handler code excluded

(defn start-server
  "used for starting the server in development mode from REPL"
  [& [port]]
  (let [port (if port (Integer/parseInt port) 5000)]
    (reset! server
            (run-server (get-handler)
                        {:port port
                         :auto-reload? true}))
    (println (str "You can view the site at http://localhost:" port)))  
  (def fw-system
    (fw/start-figwheel!
     {:figwheel-options {:http-server-root "public"
                         :server-port 3449}
      :build-ids ["app"]
      :all-builds [{:id "app"
                    :source-paths ["src/cljs" "env/dev/cljs"]
                    :compiler {.....}
                   {:id "test"
                    .....}
                   {:id "devcards"
                    ....}]}))
    ;; watch for changes to css
  (fw/css-watcher {:watch-paths ["resources/public/css"]})
  ;; start Dirac Devtools Agent, allows cljs repl within Chrome Canary
  (dirac.agent/boot! {:nrepl-server {:port 7002}}))

[smee]

I will test without CIDER and report back

[darwin]

Please open internal DevTools for Dirac itself as described here.

Try to reproduce it again and look for more details in the internal DevTools console. You might even be able to enable breaking on "caught exceptions" so you will get better view.

[darwin]

Still Dirac is compiled in advanced mode, so it will be a mess, but you might spot something there. Especially the serialized string message which Dirac tries to unserialize would be interesting to see.

[smee]

Ok, so without CIDER it seems to work. With CIDER I can see that direc receives a message containing docs of all loaded functions of all namespace (at least it looks that way) starting like {:changed-namespaces {:recom.popover {:aliases {}, :interns {}}, :cljs.tools.reader {....

Deep within this message that gets parsed via cljs.reader there is a keyword :/ which it doesn't like, see the screenshot. I tried to create this keyword in the clojurescript repl, which works. But there is an exception when trying to read it via (cljs.reader/read-string ":/"). So, maybe that's a bug in clojurescript, what do you think?

[smee]

Clojurescript follows the EDN spec, which states

Per the symbol rules above, :/ and :/anything are not legal keywords.

Therefore, whoever serialized the function name / as :/ was wrong if he expected clojurescript to be able to read it back. Since CIDER doesn't seem to expect a clojurescript reader and it happens to work in clojure (I found no documentation stating whether or not :/ is a valid keyword) this seems to be the problem. I will ask over there.

[darwin]

Thanks for this detailed investigation.

It makes sense. nREPL wasn't really designed with ClojureScript in mind. Piggieback is kind a hack. Usual nREPL clients are implement in Clojure, so nobody probably hit this issue before.

One thing we could do is making Dirac nREPL message deserialization more robust.
You could try to implement some dirty regex patching there.

dirac/src/lib/dirac/lib/ws_client.cljs

Line 54 in a4370b7

(read-string unserialized-msg)

But I'm thinking about filtering messages on nREPL server side (in Dirac agent). Because Dirac does not expect receiving such messages and will bark right at the next step when trying to interpret unserialized message:

dirac/src/implant/dirac/implant/nrepl_tunnel_client.cljs

Line 98 in a4370b7

:else (warn "received an unrecognized message from nREPL server" (envelope message))))

Or making nrepl_tunnel_client silent about unrecognized messages. Which I don't like, because some messages might expect some kind of answer and it would break anyways. Just silently.

[darwin]

Also to add. You just hit one weird corner case in EDN deserialization. I've seen some other nREPL messages encoding "native" Clojure objects. These things cannot possibly be deserialized on ClojureScript side, at least not without some dark magic.

for example something like:

> (pr-str (atom [1 2 3]))
"#object[clojure.lang.Atom 0x3b862c81 {:status :ready, :val [1 2 3]}]"