cider 2025-04-24

we upgraded cider-nrepl to 0.55.1 and today we had the case, where 11 cpus ran at 100% for around 45 minutes until we killed the process. I ran jstack and it looks like it has to do with latest changes to track-state

"clojure-agent-send-off-pool-7" #88 [3077360] prio=5 os_prio=0 cpu=2571688.20ms elapsed=3094.35s allocated=663M defined_classes=6 tid=0x00007fc44400a090 nid=30
0007fc4275fc000]
   java.lang.Thread.State: RUNNABLE
        at java.util.WeakHashMap.get(java.base@21.0.3/WeakHashMap.java:415)
        at cider.nrepl.middleware.track_state$get_metadata_if_changed_QMARK_.invokeStatic(track_state.clj:74)
        at cider.nrepl.middleware.track_state$get_metadata_if_changed_QMARK_.invoke(track_state.clj:69)
        at cider.nrepl.middleware.track_state$compute_var_meta.invokeStatic(track_state.clj:96)
        at cider.nrepl.middleware.track_state$compute_var_meta.invoke(track_state.clj:89)
        at cider.nrepl.middleware.track_state$compute_var_metas_for_namespace$fn__96498.invoke(track_state.clj:128)
        at clojure.lang.PersistentHashMap$NodeSeq.kvreduce(PersistentHashMap.java:1309)
        at clojure.lang.PersistentHashMap$BitmapIndexedNode.kvreduce(PersistentHashMap.java:804)
        at clojure.lang.PersistentHashMap$NodeSeq.kvreduce(PersistentHashMap.java:1314)
        at clojure.lang.PersistentHashMap$BitmapIndexedNode.kvreduce(PersistentHashMap.java:804)
        at clojure.lang.PersistentHashMap$ArrayNode.kvreduce(PersistentHashMap.java:468)
        at clojure.lang.PersistentHashMap.kvreduce(PersistentHashMap.java:238)
        at clojure.core$fn__8555.invokeStatic(core.clj:6987)
        at clojure.core$fn__8555.invoke(core.clj:6967)
        at clojure.core.protocols$fn__8283$G__8278__8292.invoke(protocols.clj:174)
        at clojure.core$reduce_kv.invokeStatic(core.clj:6998)
        at clojure.core$reduce_kv.invoke(core.clj:6989)
        at cider.nrepl.middleware.track_state$compute_var_metas_for_namespace.invokeStatic(track_state.clj:123)
        at cider.nrepl.middleware.track_state$compute_var_metas_for_namespace.invoke(track_state.clj:114)
        at cider.nrepl.middleware.track_state$ns_state.invokeStatic(track_state.clj:208)
        at cider.nrepl.middleware.track_state$ns_state.invoke(track_state.clj:203)
        at cider.nrepl.middleware.track_state$initial_project_state$fn__96550.invoke(track_state.clj:257)
        at clojure.lang.ArrayChunk.reduce(ArrayChunk.java:65)
        at clojure.core.protocols$fn__8270.invokeStatic(protocols.clj:135)
        at clojure.core.protocols$fn__8270.invoke(protocols.clj:123)
        at clojure.core.protocols$fn__8229$G__8224__8238.invoke(protocols.clj:19)
        at clojure.core.protocols$seq_reduce.invokeStatic(protocols.clj:31)
        at clojure.core.protocols$fn__8262.invokeStatic(protocols.clj:74)
        at clojure.core.protocols$fn__8262.invoke(protocols.clj:74)
        at clojure.core.protocols$fn__8203$G__8198__8216.invoke(protocols.clj:13)
        at clojure.core$reduce.invokeStatic(core.clj:6965)
        at clojure.core$reduce.invoke(core.clj:6947)
        at cider.nrepl.middleware.track_state$initial_project_state.invokeStatic(track_state.clj:253)
        at cider.nrepl.middleware.track_state$initial_project_state.invoke(track_state.clj:250)
        at cider.nrepl.middleware.track_state$calculate_changed_project_state_response.invokeStatic(track_state.clj:315)
        at cider.nrepl.middleware.track_state$calculate_changed_project_state_response.invoke(track_state.clj:294)
        at cider.nrepl.middleware.track_state$make_transport$reify__96576$fn__96578.invoke(track_state.clj:341)
        at clojure.core$binding_conveyor_fn$fn__5842.invoke(core.clj:2047)
        at clojure.lang.AFn.call(AFn.java:18)
        at java.util.concurrent.FutureTask.run(java.base@21.0.3/FutureTask.java:317)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@21.0.3/ThreadPoolExecutor.java:1144)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@21.0.3/ThreadPoolExecutor.java:642)
        at java.lang.Thread.runWith(java.base@21.0.3/Thread.java:1596)
        at java.lang.Thread.run(java.base@21.0.3/Thread.java:1583)

Oof, sorry to hear that. Does this reproduce reliably in one project? In all projects?

@holger311 @kommen have you been able to reproduce it already?

I assume this didn't happen on an open-source project?

@alexyakushev no, but can add you on github if it helps

itโ€™s not exactly light on deps either

All the merrier, recent track-state changes were specifically done for large projects.

It would be easier to find out what's going on if I had the access to the project, but I understand if it is too hard process-wise

@alexyakushev sent you an invite on github

thanks a lot for you help btw!

Np. I break it, I fix it ๐Ÿ˜„

๐Ÿ™ƒ 1

no luck in reproducing it til yet

we tried: connecting with cider and evaling some namespaces and code (I saw sate messages in the nrepl log). disconnecting/connecting multiple times. connecting two sessions at the same time.

@alexyakushev any idea what else we could have tried?

what would we lose/miss if we remove it from prod?

Very little. I suggested that to @mkvlr in DM.

yes, we will do this and remove the middleware for now in prod. thanks!

If you encounter this ever again, please report back here. I also created an issue: https://github.com/clojure-emacs/cider-nrepl/issues/936

๐Ÿ™ 1

This issue is hopefully fixed in cider-nrepl 0.55.7.

is it normal that when expanding a macro with C-C RET that I loose meta data? maybe thereโ€™s something wrong with my macro, but I get the feeling that Iโ€™m loosing meta data. for example when I expand the following.

(dsdefn f 
  ([[a b] c d] 12)
  ([a [b c] d] 13)
  ([a b [^Ratio c d]] 14)
  ([a b [^integer? c d]] 15)
  ([a b [^Number c d]] 16)
  ([a b [^Double c d]] 17))
What I see is the following.
(def f
 (rte-case/dsfn
   ([[a b] c d] 12)
   ([a [b c] d] 13)
   ([a b [c d]] 14)
   ([a b [c d]] 15)
   ([a b [c d]] 16)
   ([a b [c d]] 17)))
Hereโ€™s the code for the macro. Do I need to do something special to keep metadata?
(defmacro dsdefn 
  [name & forms]
  `(def ~name (dsfn ~@forms)))

metadata is not typically visible

there is a print-metadata option you could set

๐Ÿ‘๐Ÿป 1

(doc *print-meta*)
-------------------------
clojure.core/*print-meta*
  If set to logical true, when printing an object, its metadata will also
  be printed in a form that can be read back by the reader.

  Defaults to false.
this is what might be helpful to you

Is it possible to configure Cider so that it would support the https://github.com/clj-commons/formatter/issues/9#issuecomment-446167649 indentation used by https://github.com/oakmac/standard-clojure-style-js/? I've configured clojure-mode to use the 'always-indent style https://metaredux.com/posts/2024/02/19/configuring-fixed-tonsky-indentation-in-clojure-mode.html. However, this doesn't recognize the Rule 3 exception. So, for example, if I have the following piece of code:

(foo bar
     baz
  quax)
...and I run indent-region, I get this:
(foo bar
  baz
  quax)
What I'd hope to get is this: (according to Rule 3, quax should be aligned)
(foo bar
     baz
     quax)

That's what I expected too ๐Ÿซค

For the record, I also asked this question in the Standard Clojure Style repo (https://github.com/oakmac/standard-clojure-style-js/issues/194)

I'm not expert on this, but I doubt it is possible. Enforcing such rule would make indentation depend on previous indentation โ€“ a mechanism we didn't have anywhere before.

๐Ÿ‘ 1