nrepl

dominicm 2026-06-08T10:19:28.109169Z

https://spec.nrepl.org/ Looking at clone = serial > Some servers may wish to implement sessions. Requests and responses may be sent inside a session, which has two effects: all requests within one session are run in serial; that is, no request can be accepted until the previous one has completed. In addition, thread-local state (if applicable) should be kept consistent across a session. It's sometimes useful to have serial execution without preserving thread local state - e.g. Running the (ns) preamble that cider.el sends should block any user evaluation in that namespace, but it should not clobber *1/*2/*e etc. (also @borkdude your nREPL implementations violate this rule:stuck_out_tongue:)

borkdude 2026-06-08T10:23:28.159649Z

which of the n nREPL implementations do you mean

dominicm 2026-06-08T10:24:08.843929Z

babashka's seems to pollute *1 across sessions, but I could need to dig in deeper on that.

borkdude 2026-06-08T10:24:30.574609Z

feel free to post a github issue about it

dominicm 2026-06-08T10:27:41.805829Z

What's your preferred way to receive a repro? clj-nrepl-eval cli with raw ops ok?

borkdude 2026-06-08T10:29:06.517709Z

yep!

oyakushev 2026-06-08T15:37:53.443349Z

The wording you quoted is mine, and it is not entirely true either. Not all requests that go through the session run in serial, but only those that are "eval-like" (e.g., eval, load-file, basically it's on middleware to decide). Other ops can run in parallel if they want (e.g. completions), passing a session has no effect on parallelism. Specs are hard.

dominicm 2026-06-08T16:38:37.339079Z

I was focused on evaluation, but that makes sense. My parallel tooling sessions are for evaluations that the user didn't initiate themselves.

👍 1