State middleware not detecting correct repl type

[arichiardi]

I am launching a REPL (a shadow cljs REPL) and I would like to use cider-switch-to-repl-buffer.

Expected behavior

The buffer with the REPL should open.

Actual behavior

I receive:

No cljs REPLs in current session "project-name:localhost:33275"

Steps to reproduce the problem

Launch a cljs REPL in a cljs buffer and execute cider-switch-to-repl-buffer command.

Environment & Version information

CIDER version information

latest master

The sesman-browser shows:

1: project-name:localhost:33275
      linked-to: buf(http.cljs)  proj(project-name-dir)  
        objects: *cider-repl %s(clj)*  

Debugging more, it looks like the REPL type of the above is clj and not the expected cljs for some reason. This is why the command fails.

ELISP> (car (cider-repl-buffers))
#<buffer *cider-repl project-name:localhost:33275(clj)
*>
ELISP> (defvar b (car (cider-repl-buffers)))
b
ELISP> (cider-repl-type b)
"clj"

---

It turns out that the problem is upstream, maybe with sesman but I am not sure.

The clue is in the sesman-browser

objects: *cider-repl %s(clj)*

which indicates there might be a format going wrong somewhere because in normal situations I see

objects: *cider-repl (cljs:shadow)*

Sometimes I also see

objects: *cider-repl %s(cljs:shadow)*  

So I am renaming the issue.

[bbatsov]

That's not in sesman - it's in CIDER, as it has always been. You should take a look at the message interchange between CIDER and nREPL when you're starting the REPL. How exactly do you start this REPL?

[arichiardi]

I am starting with cider-jack-in-cljs and sometimes it works sometimes it does not. Cannot reproduce consistently the three behaviours above.

[dpsutton]

recently vspinu added a pending-cljs repl type. Is it possible you are trying to do this before your cljs repl "becomes" a cljs repl?

[arichiardi]

No I would exclude that - as I described above, the sesman-browser shows different things at each Jack in. Once the REPL detected wrong...must be something else if we are sure it is not sesman.

[bbatsov]

It's not. The REPL type has always been set by the track-state middleware. That's why I suggested looking at *nrepl-messages*.

[arichiardi]

will do

[runejuhl]

I think I'm hitting this same issue -- what can I do to aid in debugging?

From a fresh emacs instance (emacs -Q) I open my Clojurescript project and do a cider-jack-in-cljs. When prompted for a ClojureScript REPL type I select "figwheel". Until a browser to connects to Figwheel, the CLJS repl buffer shows "pending-cljs". After the browser connects the repl buffer shows that it's of type "clj" instead of the expected "cljs".

After setting cider-repl-auto-detect-type to nil the same sequence of operations results in a cider-repl buffer that shows "pending-cljs" indefinitely.

This is all using CIDER 0.18.1snapshot (package: 20180917.1746), nREPL 0.2.12 and Clojure 1.9.0, Java 10.0.2.

[vspinu]

format going wrong somewhere because in normal situations I see

No. That %s is a placeholder for the connection name which is commonly long. Otherwise you get plenty of redundant strings out there. It's strange that you don't get %s on some occasions. Do you customize nrepl-repl-buffer-name-template? That configuration option changed considerably in the last version.

After setting cider-repl-auto-detect-type to nil the same sequence of operations results in a cider-repl buffer that shows "pending-cljs" indefinitely.

One could in principle "fix" this by using cljs instead of pending-cljs when cider-repl-auto-detect-type is nil, but that would mean that we will keep running around the bush instead of fixing the root of the problem. I cannot reproduce this with figwheel but hopefully will have a better chance with shadow which I still have to figure out how to use.

I would suggest that we change the name of this issue to "State middleware not detecting correct repl type" or likewise (I think we have a similar issues open somewhere). It's not sesman related in any case.

[arichiardi]

No. That %s is a placeholder for the connection name which is commonly long. Otherwise you get plenty of redundant strings out there. It's strange that you don't get %s on some occasions. Do you customize nrepl-repl-buffer-name-template? That configuration option changed considerably in the last version.

Nope, that var is the default in my conf but I will double check.

[narendraj9]

I think I am hitting this bug. When I do cider-jack-in-clj&cljs, it doesn't work somtetimes. The cljs repl shows that it's a pending-cljs repl and not buffers are connected to it.

I thought it was consistently happening and then I saw it working for the first time today.

[WorldsEndless]

Verified that this is a problem for me too, whether I try to do cider-jackin-clj&cljs or a later manual jack-in of just a cljs buffer.

[bbatsov]

Check out http://www.cider.mx/en/latest/troubleshooting/ and provide us with more details, please. In particular - the nREPL message exchange would be pretty useful.

Also - are all of you using the latest piggieback?

[runejuhl]

@bbatsov nope -- and that was the problem in my case. Upgraded to latest piggieback ([cider/piggieback "0.3.9"]) and presto, everything worked again.

Thank you for the help!

[mallt]

I'm experiencing the same issue even when using the latest piggieback. The issue can be reproduced consistenly on my machine by creating a new reagent project with lein new reagent *project-name* and then running cider-jack-in-clj&cljs.

At first 2 CIDER repl's are created, 1 with type clj and 1 with type pending-cljs:

In the pending-cljs repl the message Prompt will show when Figwheel connects to your application is shown. When I then open a browser on localhost:3449, the clj repl becomes a cljs repl, and the pending-cljs one stays:

[AndrewBallinger]

I'm seeing the same thing. In my case the steps to reproduce are a little bit different.

1. cider-jack-in-cljs.
2. Wait a while, browser opens, figwheel loads everything, freezes on
   Opening URL http://localhost:9500.
   Notably the figwheel template says connected, but there's no evidence of this. Compiled clojurescript runs.
3. Hangs out in "pending-cljs" state, no amount of reloading the browser does anything.

Without digging in too much, hitting Ctrl-C in the cider buffer and then
(figwheel.main/reset) on the resulting clojure prompt connects. From there, everything seems to be working. Hoping this work-around helps to debug the issue.

[mallt]

In my case this issue seems to be fixed by #2484 (tested with CIDER 0.19.0snapshot (package: 20181118.1736)).

Thanks a lot @kommen!

[kommen]

Asking as @mallt mentioned this was solved for him: Is this still an issue for other people?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!

[bbatsov]

Seems it's not, so I'll be closing this.