(melpa-unstable or Git master, that is)

Melpa is melpa, I assume. The other one is usually referred to melpa stable.

Normally I try to maximize clarity in communications as not everyone is familiar with melpa intricacies. For that matter, people keep re-discovering 'the bad way' (start the work day with a bug, etc) that most often what they want is to use Stable for most packages (or the equivalent Git tag)

Anyway, we have a stable release around the corner! In big part thanks to your awesome streak of contribs 🙌

What happens if you run kaocha-runner-run-tests and the like? Seems its intended usage

Then I just see the bright green text, and it finishes in about 100 ms (or less).

Nice Maybe you have some extra setup code that bridges kaocha with cider? Like an advice-add I don't see anything in https://github.com/magnars/kaocha-runner.el/blob/master/kaocha-runner.el that would do something 'magical', fortunately

Here’s pure kaocha-runner.el:

Note: I’m on Doom Emacs, I should have included that piece of information. Doom may be doing something weird.

GNU Emacs     v29.1            nil
Doom core     v3.0.0-pre       HEAD -> master 9620bb45 2024-04-18 14:20:48 -0400
Doom modules  v24.04.0-pre     HEAD -> master 9620bb45 2024-04-18 14:20:48 -0400

I'd grep for kaocha within all your emacs files (doom and otherwise)

Within my Emacs config, this is all I’ve got:

Exported grep results:

config.el:194:  (kaocha-runner-run-all-tests)
config.el:506:(use-package! kaocha-runner)
packages.el:56:(package! kaocha-runner)

config.el:194:  (kaocha-runner-run-all-tests)

It’s inside a function I use to run my tests from a REPL:

(defun teod-reload+test ()
  (interactive)
  (auto-revert-mode 1)
  (projectile-save-project-buffers)
  (cider-interactive-eval "(do (require 'clj-reload.core) (clj-reload.core/reload))")
  (kaocha-runner-run-all-tests)
  ;; (cider-test-run-project-tests nil)
  )

(map! :g "M-RET" #'teod-reload+test)

I can’t find find any references to kaocha from within the Doom Emacs mode for Clojure. I looked through the code, didn’t see anything that looked weird. https://github.com/doomemacs/doomemacs/tree/9620bb45ac4cd7b0274c497b2d9d93c4ad9364ee/modules/lang/clojure/

I ran out of ideas Maybe this scenario is familiar to @U07FCNURX?

Quick idea, M-x describe-function cider-test-run-project-tests might reveal any present advice

I’m seeing this:

cider-test-run-project-tests is an interactive byte-compiled Lisp function in
'cider-test.el'.

(cider-test-run-project-tests PROMPT-FOR-FILTERS)

Run all tests defined in all project namespaces, loading these as needed.

If PROMPT-FOR-FILTERS is non-nil, prompt the user for a test selectors to
filter the tests with.

Yeah looks normal -- Another idea, maybe it's related to Kaocha itself? The JVM side, that is I'm not too familiar with it, but perhaps there's a watcher or hook, something like that

Perhaps — but then I’d have a hard time explaining why kaocha-runner.el-styled test output shows up in my Emacs!

Does it happen if you never used kaocha-runner.el in the current emacs session?

Also, feel free to paste here the nrepl logs: • restart emacs • (setq nrepl-log-messages t) • repro bug • grab contents of *nrepl-messages-<repl name>*

Sorry, got distracted. I’ll try without using kaocha-runner.el and get the nrepl logs.

> Does it happen if you never used kaocha-runner.el in the current emacs session? No.

1. I do not observe a double test run when I’ve never loaded kaocha-runner 2. I do not observe a double test run when I’ve loaded kaocha-runner but never used it 3. I do observe a double test run when I’ve run a kaocha-runner test run first (`M-x kaocha-runner-run-all-tests`), and then later run the tests with CIDER (`M-x cider-test-run-project-tests`) NREPL logs attached. They are a bit longer than they could be, I had to mess around a bit in order to reproduce the double test run. I’ll try make a shorter one next.

Shorter reproduction. I did the following: 1. Turned on NREPL logs 2. Ran tests with kaocha-runner once 3. Ran tests with cider-test once

Thanks! I'll take a look later today My theory is that Kaocha's cider-nrepl-request:eval never completes (this is a usual characteristic of nrepl requests - they keep waiting for stdout indefinitely) and captures output triggered by later cider-test-run-project-tests calls

Awesome! And thanks for CIDER; CIDER is still awesome. I’m happy try more things to reproduce if that’s helpful.

That is interesting. It's almost like asynchronous callback based code is hard to get right. 😅 I wonder why it never completes, tho. One solution would be to add a timeout, I guess, but that would only be treating symptoms.

Even adding a timeout is a problem, given I don't know how long your tests are supposed to run. From what I can tell judging by this thread, the different cider-nrepl-requests are receiving each others callbacks, is that right? In that case, how do other libs work around this issue?

This is not a fix, but it hopefully reduces the fallout somewhat: https://github.com/magnars/kaocha-runner.el/commit/1bcb19e2e2b169f05d61ef0420bedc283bcbc648

Thanks! I haven't had the proper chance to take a look at the whole thing again, sorry

If it was easy, everyone would do it 🔥

"I ask not for a lighter burden, but for broader shoulders." -Unknown