So here is the example:

Some more detail around the issue • Running the (/ 1 0) in a try catch responds instantly • The issue does not occur for a co-worker using intelliJ/cursive • The issue does not occur in other smaller projects I am working on • This started happening a couple of months ago. • This project is an older lein monorepo. I am not sure of where to look next :thinking_face:

It’s very interesting that you can evaluate and get answers while waiting for that exception. It must be spawning off a thread inside there somewhere.

Can you try with connecting some other nREPL client instead of Calva? Something like so: 1. Use the command Calva: Copy Jack-in Command-line 2. Paste that command in a terminal at the project root. 3. In another terminal, from the same project root: lein repl :connect If it doesn’t happen there, we know something (unclear to me right now, but at least that it is specifically Calva related). If it happens there too we also know something (also a bit unclear to me what, I am a bad scientist here…).

So the current environment means that this project runs in a container and we connect over a static nrepl port with Calva: Connect to a running repl server in this project Lein didn’t seem to want to pick up the .nrepl-port file so I just connected directly with: clj -Sdeps '{:deps {nrepl/nrepl {:mvn/version "0.5.3"}}}' -m nrepl.cmdline -c --host 127.0.0.1 --port 8390 And this is what followed:

Which would suggest that it is calva related. But also has to be something to do with this project :thinking_face: A weird and wonderful intersection.

Thanks. Calva has an nrepl message log that can be enabled. iirc Calva: Toogle nREPL logging enabled (or something). Unfortunately Leiningen’s nREPL client doesn’t have this, but maybe we can learn something from Calva’s log.

Thank you! Taking time out of your day for this is much appreciated 😄 Will enable that logging and see what I can find.

Ohh interesting… So by the looks of things, the exceptions comes back right away and the stacktrace is what takes so long to return? If i am reading that correctly.

Ah, yes. Very interesting. Please file an issue about it. We can make Calva not wait for the stack trace before printing the message.

Another test you could do is evaluating *e after having evaluated the divide-by-zero. In both Calva and from the Leiningen nrepl client (which is actually REPL-y, I think).

Sure thing I will set that up. I should also use this as an excuse to make some contributions back to calva. So will see if I can knock of some lower hanging fruit to say thanks for all the work you put into it :dancer:

Good that it wasn’t some thread started in the REPL somewhere.

Interesting result from checking *e It would appear that it populates immediately after the exception Here in the video *e started with an NPE and as soon as I evaluated the (/ 1 0) It was correctly updated to a division exception So I wonder how or why the response is taking so long :thinking_face:

Could this warning at the end be related by any chance?

1700658239942 <- received 0ms
{
  id: '11',
  msg: 'The `stacktrace` op is deprecated, please use `analyze-last-stacktrace` instead.',
  session: 'edc9d13f-117d-4e7c-8946-66940524071e',
  status: [ 'notification' ],
  type: 'warning'
}

Worth a try. If you have some time I can pair with you setting the dev environment up and finding some interesting spots in the mess (my affectionate name for the codebase).

That would be greatly appreciated if it’s not too much trouble. When would work for you?

Now would work. 😃 If not, suggest a time and I’ll make it work.

Perfect, ready when you are. 😄