No. this is since 1.11 just bump your core.async (usually, core.async is the one that requires the core.analyze)

lein deps :tree | less or clj -Stree | less and search who is requiring the clojure/analyzer easy solution (i do this): just add the latest analyzer to your deps [org.clojure/tools.analyzer.jvm "1.2.3"]

> Doesn't an excessive dependency tell people who might need to run against an older Clojure they are out of luck? no. it is fine to ignore those warnings. thre is no broken code or anything like that.

Ah, my old buddy cljs.http 0.1.46, with no indication it will ever move forward, pulls in org.clojure/core.async "0.4.474" I could fork it I suppose and bump the async, but it is there only to support a test. Thx for the tip on lein deps :tree, I forgot about that! 🙏

Again: I'd just add a core.async directly in my deps.

Damn, someday I should read the leiningen doc! 🙂 But the beauty of lein is that we can get so far without needing to.

Works for me

$  java --version
openjdk 19.0.2 2023-01-17
OpenJDK Runtime Environment (Red_Hat-19.0.2.0.7-1.rolling.fc37) (build 19.0.2+7)
OpenJDK 64-Bit Server VM (Red_Hat-19.0.2.0.7-1.rolling.fc37) (build 19.0.2+7, mixed mode, sharing)

$ clj
Clojure 1.11.1
(with-redefs [type (constantly java.lang.String)
                class (constantly 10)]
    [(type [])
     (class [])])
[java.lang.String 10]

@U0JUM502E Do you by any chance have direct linking enabled?

$ clj -J-Dclojure.compiler.direct-linking=true
Clojure 1.10.3
(with-redefs [type (constantly java.lang.String)
                class (constantly 10)]
    [(type [])
     (class [])])
[clojure.lang.PersistentVector clojure.lang.PersistentVector]

Oh ok, yes. Thanks @U04V15CAJ! I've lifted that into the prod profile 😃...

Even in prod this can bite you, if you like to REPL into production and patch things here and there, just something to be aware of :)

Fair point, for this project it's not viable, but good to be aware 😉...

"my *%* father %s is %s" "living" That first % needs to be %s . You have an invalid format string

user=> (taoensso.timbre/debugf "my % father %s is %s" "living" "john" "nextdoor")
Execution error (IllegalFormatConversionException) at java.util.Formatter$FormatSpecifier/failConversion (Formatter.java:4442).
f != java.lang.String

I know what the issue is, thanks

user=> (taoensso.timbre/debugf "my %s father %s is %s" "living" "john" "nextdoor")
2023-03-24T14:52:03.385Z  DEBUG [user:1] - my living father john is nextdoor

My question is why the Exception is omitted in lein test

ah apologies

no problem 🙂

are there multiple threads involved?

yes

multiple thread, not concurrent, but uses ThreadPoolExecutor

At first I though it might be because the reduce function its in has side effects, but other side effects get logged / executed just fine.

my guess is the thread you expect to produce a value dies and your test harness is still expecting a value to come from that thread?

It's just the Exception that doesn't get printed/logged when using lein test but does get logged when running the project

Is the exception coming from test code or from the fixture?

Fixtures can behave oddly if exceptions bubble out of them

(whatever weirdness with exceptions and fixtures I think I recall may have been fixed)

The Exception should be thrown by the mentioned debugf from timbre, but isn't. Or atleast, it is probably thrown but not shown or printed or logged anywhere

If Kondo would pick up the incomplete formatter I would have found it sooner tho 🙂

will see if I can enable this somehow

still strange the Exception isnt thrown tho

oh, the exception is almost certainly thrown

You are indeed right, it's just not logged/printed anywhere

you might have an uncaught exception handler or something in production that logs things

thing is, if I forcefully create something that should thrown an Exception anywhere in the process, the Exception gets thrown like it should

thrown and logged/printed I mean

this specific Exception just isnt logged/printed in the unittest, but is when manually testing the process

are you sure in your tests to force an exception you are doing that on the same thread where the bad logging statement would be run?

I think I am, but I will check again

I tried testing the separate process function and it does print/log the thrown Exception. But if I wrap the function in a clojure.core.async/thread it's not printed in my repl but I get a message in the Calva terminal:

Exception: clojure.lang.ExceptionInfo thrown from the UncaughtExceptionHandler in thread "async-thread-macro-1"

The process isnt run in core.async thread tho

sure, but it is run in another thread, how is that other thread started?

you're running your own threadpool?

how do you know the faulty logging is actually being run?

are you waiting for the thread it runs on to complete?

If I run the process without lein test with a subset of data the process gets queued using these imports:

[clojure.lang Var]
[java.util.concurrent ConcurrentHashMap Executors RejectedExecutionException]
[java.util.function Function]

When I use the unittest the statemanagement stops the process due to the internal Exception handler catching it, what it does otherwise aswell

its just not printed during the unit test

when you run the processs outside of testing, does the process hang around after the exception is printed out?

If I do this manually using async/thread it does and I need to interrupt evaluation. It doesn't when testing the process using test data in a live non production environment

its just strange it doesnt get logged. the issue is solved, but for faster debugging it would be a nice to have haha

I would try putting a sleep of a few seconds in before the statemanagement stuff stops anything

not as a fix or anything, but just to see if that causes whatever to get printed / logged

to be clear you expect it to be logged or printed? (going out through print/prn or out through timbre)

I seem to recall timbre failing to flush the stream it is writing to, so you can lose log messages on exit that way (but haven't used timbre in a while, and when I did it drove me nuts so I might be misremembering it unfavorably)

Out through timbre

you might also add a class to (flush) before the statemanagement stuff tears things down

The statemanagement is run by a fixture in the unitest. Ill add the flush there. Might be that is what's not logging the exception as its a try with finally and no catch

I can get the Exception to be logged/printed if I wrap the formatting line that causes the error in a separate try catch block

some somewhere its not catching it properly to be thrown back to the test run

I've found the source of the issue. The function that formats the log output is the culprit. I've added a try catch there and now the error and stacktrace get nicely logged