2025-03-21 core-async | Clojure Slack Archive

core-async

Andrew Leverette 2025-03-21T18:12:36.220779Z

Does async functionality change in protocols? For example I have a protocol and a record defined like this:

(defprotocol DataWriter
  "Protocol for writing data to a file"
  (write [this path data opts])
  (write-async [this path data opts]))

(defrecord DefaultDataWriter []
  DataWriter
  (write [this path data _options]
    (try
      (with-open [w (io/writer path)]
        (.write w data)
        {:path path})
      (catch Exception e
        (throw (ex-info "Error writing data" {:path path :writer-type :default} e)))))

  (write-async [this path data options]
    (async/thread
      (write this path data options))))

When I call the write-async function on the record, the file gets created but no content is written. If I just define a function like this:

(defn write-async
  [path data]
  (async/thread
    (try
      (with-open [w (io/writer path)]
        (.write w data)
        {:path path})
      (catch Exception e
        (throw (ex-info "Error writing file" {:path path} e))))))

This works. Am I doing something wrong here?

phronmophobic 2025-03-21T18:17:35.850639Z

> Does async functionality change in protocols? Not that I'm aware. I strongly suspect the problem is somewhere else.

phronmophobic 2025-03-21T18:18:52.930149Z

I have noticed that running code in go blocks or thread blocks might cause errors not to be printed to the repl. You may want to add some logging, printing, tapping, or otherwise to see if an error is happening inside the asynchronous scope.

phronmophobic 2025-03-21T18:21:11.647319Z

Generally speaking, it's usually a bad idea to have my-operation and my-operation-async. If someone wants to make an operation asynchronous, it's pretty trivial to wrap it in a go block, thread block, or run the operation using an Executor. Providing a my-operation-async is making a policy decision in a library that is usually made globally with more context.

2025-03-21T19:58:28.866969Z

My guess would be something is throwing an exception before the write (file created no content)

2025-03-21T19:59:09.682519Z

Channels are queues between threads of control, they don't convey errors between threads like say futures

Andrew Leverette 2025-03-21T20:26:10.055449Z

Okay, I found the issue. It was a separate issue, but here goes. The code snippet culprit is below:

(defn file-writer-worker
  [in]
  (async/go-loop []
    (when-let [{:keys [path data metadata]} (async/<! in)]
      (let [{:keys [ok? error]} (async/<! (write-data-async path data))]
        (if ok?
          (println (str "File written: " path " metadata: " metadata))
          (println (str "Error writing file: " path " metadata: " metadata " error: " error))))
      (recur))))

The recur is outside the body of the let but in the when-let. This apparently was causing an issue. I moved the recur within the let and it works.

Andrew Leverette 2025-03-21T20:28:05.758439Z

I don't quite understand why that would cause an issue.

2025-03-21T20:34:25.330239Z

Hard to say exactly, if you are hacking at the repl it is easy to have core.async related state in the repl persist beyond what you expect and alter the behavior of subsequent runs, can be tricky to debug just looking at code. A good rule of thumb is if you get unexpected behavior, restart your process (new repl or whatever) and see if it persists in a fresh environment

➕ 1

Andrew Leverette 2025-03-21T20:37:09.949199Z

Thanks for the advice.

phronmophobic 2025-03-21T20:37:35.837869Z

I highly recommend either wrapping async threads/go macros with try/catch with logging or using a macro that does it for you.

Clojurians Log v2

core-async