2025-12-18 babashka | Clojure Slack Archive

babashka

richiardiandrea 2025-12-18T14:53:31.812289Z

Hi everybody, I am trying to creat a new JVM pod and I wonder if anybody know how to I go about debugging this error

025-12-18T14:42:55.535Z RESML-MRY4XW3P44 WARN [dedushka.x-force.survey.history] - #error {
 :cause nil
 :via
 [{:type java.lang.NullPointerException
   :message nil
   :at [java.lang.String <init> "String.java" 1533]}]
 :trace
 [[java.lang.String <init> "String.java" 1533]
  [babashka.pods.impl$bytes__GT_string invokeStatic "impl.clj" 28]
  [babashka.pods.impl$processor invokeStatic "impl.clj" 206]
  [babashka.pods.sci$load_pod$fn__30523 invoke "sci.clj" 122]
  [sci.impl.vars$binding_conveyor_fn$fn__411 invoke "vars.cljc" 129]
  [clojure.core$binding_conveyor_fn$fn__5844 invoke "core.clj" 2047]
  [clojure.lang.AFn call "AFn.java" 18]
  [java.util.concurrent.FutureTask run "FutureTask.java" 328]
  [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]]}

✅ 1

borkdude 2025-12-18T14:54:46.071159Z

I recommend running with the pods library locally and then add debug stuff around the part where it fails. This looks like a null byte array

richiardiandrea 2025-12-18T14:56:51.279149Z

yeah I have all those debug (maybe I miss some?) I went to the pod code and if the location is correct it seems like it is trying to decode (with bencode) the id...

richiardiandrea 2025-12-18T14:57:13.374749Z

as it receive a blank message (that of course I never send - as far as I know)

richiardiandrea 2025-12-18T14:58:41.082199Z

is there any var that improves the verbosity of what the pod client does?

borkdude 2025-12-18T14:59:35.589959Z

just add debug stuff yourself?

richiardiandrea 2025-12-18T15:00:54.011709Z

yep yep I was just wondering but I'll check the pod client

borkdude 2025-12-18T15:01:52.566569Z

sometimes an NPE happens when you accidentally print something in the pod and send it to the stdin of the pod client

richiardiandrea 2025-12-18T15:02:07.064619Z

hmm good hunch

richiardiandrea 2025-12-18T15:10:58.680599Z

it is probably that = my pod source is actually printling something 😮 https://github.com/tolitius/verter/blob/f17bf8eb51f3e0b6e2ba77e3d9966004e7479996/src/verter/store/postgres.clj#L39

borkdude 2025-12-18T15:11:36.088119Z

print it to stderr instead :)

richiardiandrea 2025-12-18T15:11:52.703849Z

yeah now I know - I can wrap all the calls to the original code

richiardiandrea 2025-12-18T15:12:01.458919Z

thanks for the suggestion!

👍 1

richiardiandrea 2025-12-18T17:47:42.439799Z

@borkdude is there a way to add transit read/write handlers for the babashka pod client? I am getting these kinds for errors

❌ java.lang.Exception: Not supported: class java.time.Instant
#error {
 :cause "Not supported: class java.time.Instant"
 :via
 [{:type java.lang.RuntimeException
   :message "java.lang.Exception: Not supported: class java.time.Instant"
   :at [com.cognitect.transit.impl.WriterFactory$1 write "WriterFactory.java" 65]}

richiardiandrea 2025-12-18T17:53:43.591509Z

oh - found an example https://github.com/babashka/babashka-sql-pods/blob/132f0e6e67b6e4e7463d0e25b25305f05b1f6b0d/src/pod/babashka/sql.clj#L176

teodorlu 2025-12-18T18:32:17.527099Z

Should I assume that virtual threads "suspend nicely" with babashka.process/shell? Specifically, I'm shelling out to the Google Cloud CLI to get a secret (`gcloud secrets versions access latest ...`), and while that command does just sit and wait for IO, I don't know if that means it plays nicely with vthreads. I see that p/shell uses clojure.core/future under the hood (https://github.com/babashka/process/blob/be97f9e84daa352e5adb84534ea5c8d2e666fe01/src/babashka/process.cljc#L386-L395), so maybe all this doesn't matter, and I would be better served just using clojure.core/future and not care about the potentially lightened system load from virtual threads.

✅ 2

borkdude 2025-12-18T18:38:01.931599Z

p/shell doesn't use any threads I believe

teodorlu 2025-12-18T18:39:22.433579Z

Aren't these future calls executed in different threads?

out (if (and out (or (identical? :string out)
                             (identical? :bytes out)
                             (not (keyword? out))))
              (future (copy stdout out out-enc))
              stdout)
        err (if (and err (or (identical? :string err)
                             (identical? :bytes err)
                             (not (keyword? err))))
              (future (copy stderr err err-enc))
              stderr)]

(from the linked source in the original question)

borkdude 2025-12-18T18:39:46.299129Z

yes, but p/shell doesn't use out and err, it uses inherit

teodorlu 2025-12-18T18:40:27.890999Z

Aaaah, you're right. Thanks. I see that those are only created when actual output copying is required.

teodorlu 2025-12-18T18:49:42.049819Z

I think my conclusion is that yes, babashka.process/shell works nicely with virtual threads. babashka ends up calling java.lang.Process/.waitFor, which I believe parks the thread while waiting.

borkdude 2025-12-18T18:50:19.795679Z

yep

borkdude 2025-12-18T18:50:55.874719Z

probably it's worth migration bb.process to virtual threads where now future is used. but perhaps clojure 1.13 will migratre future to virtual threads? ;)

teodorlu 2025-12-18T18:55:43.614979Z

Maybe! I mistakenly assumed it did. If not, I would very much welcome a clojure.core/vtfuture.

Clojurians Log v2

babashka