Clojurians Log v2

I tried version bisecting it, and it seems that the issue appeared in v1.12.198 . I tried the following, downloading the versions from github: v1.12.196 -> works v1.12.197 -> works v1.12.198 -> handshake_failure random versions between v1.12.198..v1.12.208 -> handshake_failure

btw, running the same poc with regular clojure works without problems

define "the http client", do you mean babashka.http-client?

yes

the thing is i can only reproduce this with some specific internal hosts, i've been trying to find a public host that has this problem but I couldn't

a simple (http/get url) reproduces the problem

i really cannot understand why this worked until v1.12.197 but does not work after v1.12.198 though

Please make a Github issue with a repro. Perhaps we can find what changed between 197 and 198 in terms of: • GraalVM version on CI • Changes in babashka.http-client Also please specify your OS in the Github issue.

You can also try org.httpkit.client which is built-in. also babashka.curl

to see if they have the same problem

the poc is pretty simple, i just cannot find a url that reproduces this outside my work's private infrastructure

yeah let me try the other clients

Issue reproducible by both babashka.http-client and org.httpkit.client

Using babashka.curl works

Performed same test in both windows (employer's machine) and linux (in a docker container inside employer's machine) and the difference betwen 197 and 198 is reproducible in both of them, so it is not OS dependent

stack trace of error if it helps somehow:

#error {
 :cause "(handshake_failure) Received fatal alert: handshake_failure"
 :via
 [{:type clojure.lang.ExceptionInfo
   :message "(handshake_failure) Received fatal alert: handshake_failure"
   :data {:type :sci/error, :line 1, :column 1, :message "(handshake_failure) Received fatal alert: handshake_failure", :sci.impl/callstack #object[clojure.lang.Volatile 0x4e8f608a {:status :ready, :val ({:line 1, :column 1, :ns #object[sci.lang.Namespace 0x4e4b285b "user"], :file "C:\\Users\\User\\Workdir\\", :sci.impl/f-meta {:arglists ([uri] [uri opts]), :doc "Convenience wrapper for `request` with method `:get`", :ns #object[sci.lang.Namespace 0x3cf0b15 "babashka.http-client"], :name get}} {:line 1, :column 1, :ns #object[sci.lang.Namespace 0x4e4b285b "user"], :file "C:\\Users\\User\\Workdir\\", :sci.impl/f-meta {:arglists ([uri] [uri opts]), :doc "Convenience wrapper for `request` with method `:get`", :ns #object[sci.lang.Namespace 0x3cf0b15 "babashka.http-client"], :name get}})}], :file "C:\\Users\\User\\Workdir\\"}
   :at [sci.impl.utils$rethrow_with_location_of_node invokeStatic "utils.cljc" 140]}
  {:type javax.net.ssl.SSLHandshakeException
   :message "(handshake_failure) Received fatal alert: handshake_failure"
   :at [jdk.internal.net.http.HttpClientImpl send "HttpClientImpl.java" 928]}
  {:type javax.net.ssl.SSLHandshakeException
   :message "(handshake_failure) Received fatal alert: handshake_failure"
   :at [sun.security.ssl.Alert createSSLException "Alert.java" 130]}]
 :trace
 [[sun.security.ssl.Alert createSSLException "Alert.java" 130]
  [sun.security.ssl.Alert createSSLException "Alert.java" 117]
  [sun.security.ssl.TransportContext fatal "TransportContext.java" 363]
  [sun.security.ssl.Alert$AlertConsumer consume "Alert.java" 287]
  [sun.security.ssl.TransportContext dispatch "TransportContext.java" 202]
  [sun.security.ssl.SSLTransport decode "SSLTransport.java" 172]
  [sun.security.ssl.SSLEngineImpl decode "SSLEngineImpl.java" 734]
  [sun.security.ssl.SSLEngineImpl readRecord "SSLEngineImpl.java" 689]
  [sun.security.ssl.SSLEngineImpl unwrap "SSLEngineImpl.java" 504]
  [sun.security.ssl.SSLEngineImpl unwrap "SSLEngineImpl.java" 480]
  [javax.net.ssl.SSLEngine unwrap "SSLEngine.java" 673]
  [jdk.internal.net.http.common.SSLFlowDelegate$Reader unwrapBuffer "SSLFlowDelegate.java" 556]
  [jdk.internal.net.http.common.SSLFlowDelegate$Reader processData "SSLFlowDelegate.java" 452]
  [jdk.internal.net.http.common.SSLFlowDelegate$Reader$ReaderDownstreamPusher run "SSLFlowDelegate.java" 283]
  [jdk.internal.net.http.common.SequentialScheduler$LockingRestartableTask run "SequentialScheduler.java" 182]
  [jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask run "SequentialScheduler.java" 149]
  [jdk.internal.net.http.common.SequentialScheduler$SchedulableTask run "SequentialScheduler.java" 207]
  [java.util.concurrent.ThreadPoolExecutor runWorker "ThreadPoolExecutor.java" 1095]
  [java.util.concurrent.ThreadPoolExecutor$Worker run "ThreadPoolExecutor.java" 619]
  [java.lang.Thread runWith "Thread.java" 1460]
  [java.lang.Thread run "Thread.java" 1447]
  [com.oracle.svm.core.thread.PlatformThreads threadStartRoutine "PlatformThreads.java" 832]
  [com.oracle.svm.core.thread.PlatformThreads threadStartRoutine "PlatformThreads.java" 808]]}

Some progress on this So I run this poc:

bb -Djavax.net.debug=all -e "(require '[babashka.http-client :as http]) (http/get \"\")"

diff between log output using: -Djavax.net.debug=all

-javax.net.ssl|DEBUG|HttpClient-1-Worker-0|<datetime> UTC|ClientHello.java:640|Produced ClientHello handshake message (
+javax.net.ssl|DEBUG|HttpClient-1-Worker-0|<datetime> UTC|ClientHello.java:638|Produced ClientHello handshake message (
 "ClientHello": {
   "client version"      : "TLSv1.2",
-  "random"              : "C02680E18468257EE8E4B16446E4D5C8C98300D339F4B556975C768D213BCE23",
-  "session id"          : "D664A8DDE4770782CC330B080B8DBF0EBB8E2E578116BA4CF3CE3F2E7EBC1DEF",
-  "cipher suites"       : "[TLS_AES_256_GCM_SHA384(0x1302), TLS_AES_128_GCM_SHA256(0x1301), TLS_CHACHA20_POLY1305_SHA256(0x1303), TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256(0xCCA9), TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256(0xCCA8), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256(0xCCAA), TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]",
+  "random"              : "5A2C4BB30DFDBA28911409AEECE328E7C4CD7CBC2C0200BF09FB9352ADB05DD6",
+  "session id"          : "64EB1A16EFA7B27059B20C624B2733A00181B6957E3C7843E3BBEF2CD54880B3",
+  "cipher suites"       : "[TLS_AES_256_GCM_SHA384(0x1302), TLS_AES_128_GCM_SHA256(0x1301), TLS_CHACHA20_POLY1305_SHA256(0x1303), TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256(0xCCA9), TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256(0xCCA8), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256(0xCCAA), TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]",
...
-javax.net.ssl|DEBUG|HttpClient-1-Worker-0|<datetime> UTC|SSLEngineOutputRecord.java:529|WRITE: TLSv1.3 handshake, length = 465
+javax.net.ssl|DEBUG|HttpClient-1-Worker-0|<datetime> UTC|SSLEngineOutputRecord.java:529|WRITE: TLSv1.3 handshake, length = 453
...
-javax.net.ssl|DEBUG|HttpClient-1-Worker-0|<datetime> UTC|SSLEngineInputRecord.java:176|Raw read (
...
...
...
-)
-javax.net.ssl|DEBUG|HttpClient-1-Worker-0|<datetime> UTC|SSLEngineInputRecord.java:213|READ: TLSv1.2 handshake, length = 81
-javax.net.ssl|DEBUG|HttpClient-1-Worker-0|<datetime> UTC|ServerHello.java:892|Consuming ServerHello handshake message (
-"ServerHello": {
-  "server version"      : "TLSv1.2",
-  "random"              : "FA46A225E44E8BFD9719A2F0FF6EDC84B0A97B606F20B7D5164241193DF18496",
-  "session id"          : "B69C59D64A210DFB1FE4E28231E93402940D60B25861505E7DF6910702798413",
-  "cipher suite"        : "TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D)",
-  "compression methods" : "00",
-  "extensions"          : [
-    "renegotiation_info (65,281)": {
-      "renegotiated connection": [<no renegotiated connection>]
-    }
-  ]
-)
+javax.net.ssl|DEBUG|HttpClient-1-Worker-0|<datetime> UTC|SSLEngineInputRecord.java:176|Raw read (
+  0000: 15 03 03 00 02 02 28                               ......(
+)
+javax.net.ssl|DEBUG|HttpClient-1-Worker-0|<datetime> UTC|SSLEngineInputRecord.java:213|READ: TLSv1.2 alert, length = 2
+javax.net.ssl|DEBUG|HttpClient-1-Worker-0|<datetime> UTC|Alert.java:232|Received alert message (
+"Alert": {
+  "level"      : "fatal",
+  "description": "handshake_failure"
+)
...
-javax.net.ssl|DEBUG|HttpClient-1-Worker-0|<datetime> UTC|ServerHello.java:988|Negotiated protocol version: TLSv1.2

it seems that v198 is missing TLS_RSA_WITH_AES_256_GCM_SHA384 cipher that the server uses

To be very precise, these suites are missing from v198:

TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D)
TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C)
TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D)
TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C)
TLS_RSA_WITH_AES_256_CBC_SHA(0x0035)
TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)

And the simplest POC of all:

bb -e "(import '[javax.net.ssl SSLSocketFactory]) (run! println (.getSupportedCipherSuites (javax.net.ssl.SSLSocketFactory/getDefault)))"

this gives 37 ciphers in v197 and 31 ciphers in v198

Found it

I got bitten by jdk 24: https://www.oracle.com/java/technologies/javase/24-relnote-issues.html#JDK-8245545 (and consequently by graalvm 24 upgrade)

Issue is reproducible with regular clojure between jdk 23 and jdk 24

So now my question is, how do I edit java.security for graalvm baked apps like babashka

> Issue is reproducible with regular clojure between jdk 23 and jdk 24 Ah good to hear it's not a bug in bb. How would you fix this with normal clojure?

You remove TLS_RSA_* from jdk.tls.disabledAlgorithms property in java.security file

where is this file?

Depends on your jdk installation, on linux it is in /etc/java-openjdk/security/java.security

I asked a question in the GraalVM native-image slack channel: https://graalvm.slack.com/archives/CN9KSFB40/p1757517264072409

I guess you could use babashka.curl as a workaround meanwhile

or upgrade your servers to a safer cipher suite config

@agorglouk Good news. In the next bb version this is possible:

(deftest java-security-setProperty-test
  (is (= 37
         (bb nil '(do (java.security.Security/setProperty "jdk.tls.disabledAlgorithms" "SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature")
                      (count (.getSupportedCipherSuites (javax.net.ssl.SSLSocketFactory/getDefault))))))))

you could put this in BABASHKA_PRELOADS in your CI env or so as well

This is amazing!

I'll use the runtime trick for now :)

good. just realize it doesn't work with the current bb. but I can merge this and you can download a dev release if you want in 30 minutes or so

yeah ping me up to give it a try

Just tested bb 1.12.209-SNAPSHOT and the fix seems to be working, thank you very much!

Also, TIL about BABASHKA_PRELOADS :)

Ah it works on master? I’m preparing a PR that also allows some security file to be set with a property but I guess the move to GraalVM 25 did it

Or maybe it works in 208 as well?

i just grabbed the artifact from the java.security pr pipeline and tested it

do you want me to try the 208 release and the latest master build respectively?

Would be interesting

ok let me try these

208 does not work

and master?

master doesn't work either

ok then I know merging this is definitely the right thing to do

once I can get past failing tests in other areas :)

@agorglouk I've been talking to a GraalVM engineer and he has currently the solution to build babashka yourself with a custom java.security file that you can point to with "-J-Djava.security.properties=/tmp/java.security" Unfortunately overriding with a Java property at runtime currently doesn't work due to a bug in OpenJDK. But he has a substitution that can be applied as part of native-image and will be part of some future version of GraalVM.

Yeah I thought that the security file should be baked inside bb at some point

Do you have the change/pr in graalvm in order to keep track of it?

no, just an issue: https://github.com/oracle/graal/issues/12164#issuecomment-3346167410 the PR will be made by https://github.com/jovanstevanovic

normally the security file should not have to be baked in, but due to a bug in OpenJDK you can't override this specific property at runtime in native-image

and this will be fixed

Thanks for getting into this!

@borkdude: This just happened again out of the blue after rebooting my machine. I checked C:\\Users\\leifercf\\.m2\\repository\\org\\babashka\\json\\0.1.6\\json-0.1.6.jar and it is indeed still present.

java.io.FileNotFoundException: Could not locate babashka/json.bb, babashka/json.clj or babashka/json.cljc on classpath. user c:\Code\bamboo-utils\src\bamboo_utils.clj:2:3

I'm requiring things like this:

(ns bamboo-utils
  (:require [babashka.fs :as fs]
            [babashka.http-client :as http]
            [babashka.json :as json]
            [clojure.string :as str]))

Interesting. I see the following files in C:\Users\leifercf\.m2\repository\babashka

.
├── babashka.curl
│   └── 0.1.2
│       ├── babashka.curl-0.1.2.jar
│       ├── babashka.curl-0.1.2.jar.sha1
│       ├── babashka.curl-0.1.2.pom
│       ├── babashka.curl-0.1.2.pom.sha1
│       └── _remote.repositories
├── fs
│   └── 0.5.25
│       ├── fs-0.5.25.jar
│       ├── fs-0.5.25.jar.sha1
│       ├── fs-0.5.25.pom
│       ├── fs-0.5.25.pom.sha1
│       └── _remote.repositories
└── process
    └── 0.6.23
        ├── process-0.6.23.jar
        ├── process-0.6.23.jar.sha1
        ├── process-0.6.23.pom
        ├── process-0.6.23.pom.sha1
        └── _remote.repositories

.
├── babashka.impl.java
│   └── 0.1.10
│       ├── babashka.impl.java-0.1.10.jar
│       ├── babashka.impl.java-0.1.10.jar.sha1
│       ├── babashka.impl.java-0.1.10.pom
│       ├── babashka.impl.java-0.1.10.pom.sha1
│       └── _remote.repositories
├── cli
│   └── 0.8.66
│       ├── cli-0.8.66.jar
│       ├── cli-0.8.66.jar.sha1
│       ├── cli-0.8.66.pom
│       ├── cli-0.8.66.pom.sha1
│       └── _remote.repositories
├── http-client
│   └── 0.4.23
│       ├── http-client-0.4.23.jar
│       ├── http-client-0.4.23.jar.sha1
│       ├── http-client-0.4.23.pom
│       ├── http-client-0.4.23.pom.sha1
│       └── _remote.repositories
├── json
│   └── 0.1.6
│       ├── json-0.1.6.jar
│       ├── json-0.1.6.jar.sha1
│       ├── json-0.1.6.pom
│       ├── json-0.1.6.pom.sha1
│       └── _remote.repositories
└── sci.impl.types
    └── 0.0.2
        ├── _remote.repositories
        ├── sci.impl.types-0.0.2.jar
        ├── sci.impl.types-0.0.2.jar.sha1
        ├── sci.impl.types-0.0.2.pom
        └── sci.impl.types-0.0.2.pom.sha1

And in C:\Users\leifercf\scoop\apps\babashka, I have:

.
├── 1.12.208
│   ├── bb.exe
│   ├── install.json
│   └── manifest.json
├── 1.12.209
│   ├── bb.exe
│   ├── install.json
│   └── manifest.json
└── current -> /mnt/c/Users/leifercf/scoop/apps/babashka/1.12.209

Ah, JFC. As is often the case, I was being an idiot 🤦‍♂️ I had removed the dependency to babashka.json from my bb.edn after switching to cheshire.core when we were testing things earlier. It works again now after re-adding the dependency to my bb.edn:

{:paths ["src"]
 :deps {org.babashka/json {:mvn/version "0.1.6"}}}

Perhaps you deleted something from gitlibs or m2 folder? Try the -Sforce flag

Oh, how odd. I installed latest Java, but after reboot, it looks like my system has reverted to an older version somehow:

PS C:\Users\leifercf> java -version
java version "1.8.0_461"
Java(TM) SE Runtime Environment (build 1.8.0_461-b11)
Java HotSpot(TM) Client VM (build 25.461-b11, mixed mode, sharing)

Hmmm. Reinstalling latest Java and rebooting didn't do anything. I'm not sure how/where to use the -Sforce flag, but I'll look into that.

Just as the first argument to bb

See the help output of bb

I'm bb it via Calva in VS Code. Will try to run it "manually."

Finally managed to fix my Java version, just in case 😅

PS C:\Users\leifercf> java -version
java version "24.0.2" 2025-07-15
Java(TM) SE Runtime Environment (build 24.0.2+12-54)
Java HotSpot(TM) 64-Bit Server VM (build 24.0.2+12-54, mixed mode, sharing)

Yeah, so bb runs fine it seems:

PS C:\Users\leifercf\scoop\apps\babashka\current> .\bb.exe -Sforce
Babashka v1.12.208 REPL.
Use :repl/quit or :repl/exit to quit the REPL.
Clojure rocks, Bash reaches.

user=>

Try looking in your home folders .babashka folder and show what’s in it

And also try to run bb from the same for as Calva does it with Sforce

Try looking in your home folders .babashka folder [...]Oh, I don't even have a .babashka folder in C:\Users\leifercf

I’ll get back to you, it’s very hard for me to diagnose this from a phone

I just nuked these caches as well for good measure:

C:\Code\test\.lsp\.cache
C:\Code\test\.clj-kondo

No worries, and thanks for the help so far! In all likelihood, I'm just doing something stupid or my system is messed up.

ok, I'm back at the keyboard. So in test.clj are you using babashka.json?

Yeah, I only have two files in my project. bb.edn

{:paths ["src"]
 :deps {org.babashka/json {:mvn/version "0.1.6"}}}

(ns kuri
  (:require [babashka.http-client :as http]
            [babashka.json :as json]))

(def company-name (System/getenv "BAMBOOHR_COMPANY_NAME"))
(def api-uri (str "" company-name))
(def api-credentials {:user (System/getenv "BAMBOOHR_API_KEY") :pass "x"})

(def employees
  {:method :get
   :uri (str api-uri "/v1/employees/directory")
   :headers {"Accept" "application/json"}
   :basic-auth api-credentials})

(defn fetch
  "Execute HTTP request and get the body as JSON."
  [request]
  (-> request
      (http/request)
      :body
      (json/read-str keyword)))

(defn get-employees
  "Get data for all employees (selected fields) from BambooHR."
  []
  (let [fields-to-keep [:workEmail
                        :displayName
                        :jobTitle
                        :department
                        :division
                        :supervisor]]
    (doall (->> (fetch employees)
                :employees
                (pmap #(select-keys % fields-to-keep))))))

(comment
  (get-employees))

.
├── bb.edn
└── src
    └── kuri.clj

Note that I had everything working fine yesterday. But I shut down my PC, and when I returned today, it no longer worked 😅

This is what I have in .gitlibs:

.
└── babashka.core
    └── 52a6037bd4b632bffffb04394fb4efd0cdab6b1e
        ├── deps.edn
        ├── LICENSE
        ├── README.md
        └── src
            └── babashka
                └── core.clj

And this is what I have in .m2:

.
├── babashka.curl
│   └── 0.1.2
│       ├── babashka.curl-0.1.2.jar
│       ├── babashka.curl-0.1.2.jar.sha1
│       ├── babashka.curl-0.1.2.pom
│       ├── babashka.curl-0.1.2.pom.sha1
│       └── _remote.repositories
├── fs
│   └── 0.5.25
│       ├── fs-0.5.25.jar
│       ├── fs-0.5.25.jar.sha1
│       ├── fs-0.5.25.pom
│       ├── fs-0.5.25.pom.sha1
│       └── _remote.repositories
└── process
    └── 0.6.23
        ├── process-0.6.23.jar
        ├── process-0.6.23.jar.sha1
        ├── process-0.6.23.pom
        ├── process-0.6.23.pom.sha1
        └── _remote.repositories

It seems like something is wrong with my environment variables after rebooting. Somehow, I don't see JAVA_HOME or MAVEN_HOME there. I'm looking into that now and will try to set those manually.

What is weird is that there is no babashka.json in the mvn repo

can you check if there is a ~/.babashka/.cpcache directory? it is hidden

if you remove that, the issue should resolve itself

In this directory: /mnt/c/Users/leifercf/scoop/apps/babashka/current I only have these files:

drwxrwxrwx 1 leifericf leifericf     4096 Sep 10 11:28 .
drwxrwxrwx 1 leifericf leifericf     4096 Sep 10 11:28 ..
-rwxrwxrwx 1 leifericf leifericf 70868992 Sep  4 14:09 bb.exe
-rwxrwxrwx 1 leifericf leifericf       67 Sep 10 11:28 install.json
-rwxrwxrwx 1 leifericf leifericf      831 Sep  9 10:34 manifest.json

There is no hidden .babashka directory anywhere in my home directory, as far as I can tell 🤔 I'm doing a system-wide search for it now. Maybe it's somewhere else.

I found a cache named babashka#1.12.208#7784600.zip here: C:\Users\leifercf\scoop\cache

that's not it. maybe it would help if you just wiped your /.m2 folder and your /.gitlibs folder

or maybe just rename them, just in case

That did the trick, yeah!

Thanks a lot for the help, and sorry for wasting your time on my messed-up system. I have no idea how that broke after a reboot.

I'll try to reboot again now, to make sure it doesn't happen again 😅

nice! and no worries, this stuff happened to me too more than once

I did a reboot now and it continued to work, so that's good. Looks like it was a fluke.

@borkdude: The exact same issue (symptoms) has occurred again, and this time deleting my .m2 and .gitlibs directories, reinstalling Babashka via Scoop and Calva via VS Code, didn't resolve the issue. I don't know if it's caused by Maven, Gitlibs, Babashka installer, Calva, or something else on my Windows system. I'm still trying to pinpoint the root cause of the issue on my system, and I'll let you know if I manage to figure it out.

Also delete .babashka

If you can reproduce this please file a GitHub issue

Are you always invoking the script from the same dir?

I found a "workaround" of sorts, by changing my bb.edn from this:

{:paths ["src"]
 :deps {org.babashka/json {:mvn/version "0.1.6"}}}

{:paths ["src"]}

(ns bamboo-utils
  (:require [babashka.fs :as fs]
            [babashka.http-client :as http]
            [babashka.json :as json]
            [clojure.string :as str]))

(ns bamboo-utils
  (:require [babashka.fs :as fs]
            [babashka.http-client :as http]
            [cheshire.core :as json] ;; <- Change is here
            [clojure.string :as str]))

> Are you always invoking the script from the same dir? I'm honestly not sure. I'm just evaluating expressions inside VS Code via Calva after opening the same root project directory and starting a REPL.

It should work with bb json. The workaround you have is because now you don’t have deps. Can you answer my previous question?

My workflow is like this: 1. Start VS Code. 2. Open root folder of my project via "File -> Open Folder..." in VS Code. ◦ This folder is opened by default when I restart VS Code after having opened the folder once. 3. Use Calva to start a Babashka REPL.

Also, side note: As a primarily Mac and Linux user, I suck at Windows stuff 😅 So there's a good chance I'm doing (or not doing) something dumb.

do you work on Windows on Wednesdays? ;) last week I was in the gym when this came up and now again, so I think there's a schedule there ;)

> Do you work on Windows on Wednesdays? Yes, unfortunately 😅 I'm back in the computer games industry. > last week I was in the gym when this came up and now again, so I think there's a schedule there 😉 Hahaha! Solid hypothesis. It happens the exact moment you get on the step master.

I know something to debug perhaps:

(prn (babashka.classpath/get-classpath))

What the hell, now it's working flawlessly again (and I haven't done any changes, just rebooted my machine).

Your debug step reports this path:

; "C:\\Code\\bamboo-utils\\src;C:\\Users\\leifercf\\.m2\\repository\\org\\babashka\\json\\0.1.6\\json-0.1.6.jar;C:\\Users\\leifercf\\.m2\\repository\\org\\clojure\\data.json\\2.5.0\\data.json-2.5.0.jar"

including the leading semicolon?

if the error happens again, then print this thing again, and also check if C:\\Users\\leifercf\\.m2\\repository\\org\\babashka\\json\\0.1.6\\json-0.1.6.jar is present on your filesystem still

> including the leading semicolon? Ah! No, I believe that semicolon is just something Calva adds to its output window.

> if the error happens again, then print this thing again Affirmative! Will do.