@pez Hmm, that’s odd. We didn’t really change anything on our end in this regard, so that’s likely a change that happened in lein.

Actually the plugin is what generates the proper :repl-options, so you don’t have to do this manually.

Yeah, something changed in master - https://github.com/technomancy/leiningen/commit/3e1459a2b22db6ed39ed6a4de0f2695d1d3ceeeb

But the warning is actually about the lein middleware, not nREPL’s middleware.

(lein middleware is simply a plugin that only transforms the project map)

Not sure what we’re expected to do this here, but despite the working everything should work just fine.

OK. Checking that I understand which plugin you are referring to. If I remove [cider/cider-nrepl "0.18.0"] from the above profile, then leiningen stops complaining. Now I'll go read the links you provided. 😃

Alright, I can't make sense out of that patch. Anyway. I can ignore the warning, right?

I want to track down where from 0.2.13 -> 0.4.5 I stopped being able to decode the messages. Which version is it that is ”the same” as 0.2.13 now again?

> Alright, I can’t make sense out of that patch. Anyway. I can ignore the warning, right?

> I want to track down where from 0.2.13 -> 0.4.5 I stopped being able to decode the messages. Which version is it that is “the same” as 0.2.13 now again?

Nothing with respect to message encoding/decoding has changed between 0.2.13 and 0.4.5.

What exactly is the problem you’re encountering?

I am trying to figure out what exactly is the problem, but what happens is that lots of the decoding starts to fail and also my nrepl client goes into an infinite loop endlessly failing decoding. It doesn't necessarily have to do with the encoding of the new nrepl. The client in Calva is a bit too naive and probably very sensitive to the order in which responses come back. It is time to fix that, and maybe I should before investigating the problems it has with 0.4.5.

No idea. Seems you can really use that EDN transport (or maybe the transit ones).

At any rate - I’m 100% certain that the encoding logic hasn’t changed at all, so the problem is likely unrelated.

It seems that what my nrepl client is failing to decode is a java stack trace.

Found it. It was the figwheel-sidecar dependency that needed to be updated to 0.5.17.

Now most things work, but the test ops fail with a stack trace starting with Exception in thread "nREPL-worker-2" java.lang.IllegalArgumentException: No implementation of method: :send of protocol: #'clojure.tools.nrepl.transport/Transport found for class: nrepl.transport.FnTransport

Also this: https://clojurians.slack.com/archives/C0AB48493/p1542659815145900