Clojurians Log v2
core-async 2025-07-07
The map returned fromIs thestarthas the flow’s report and error channels. Procs can output messages to the:report-chanfor unified logging across the flow. Exceptions thrown by a step-fn or procs in the flow are all logged to the:error-chan.
:report-chan known in time for when procs are inited?
I'm trying to understand whether I need to refer to`:report-chan` in some global memory (or inject it into the flow after -- I guess -- start time)?
Why isn't it passed into the initial arg-map?
It would seem like a much more unifying way of setting the logging up if the intention was, indeed, for all procs to use this channel.👍 I was thinking through that out loud in my previous comment.
I had missed the [pid inid] pattern for message output, and was in the middle of creating some quite ugly architecture to route responses back to their requestors.
😢 goodbye ugly code.
The report-chan is returned to you in a map when you call https://clojure.github.io/core.async/clojure.core.async.flow.html#var-start you can hang onto that response to read from the channel.
If you want to output to that chan, any output from a :transform to ::flow/report will be placed on the :report-chan
is that a full [pid ::flow/report] coordinate, or just ::flow/report as the coordinate?
sorry... I'm losing it... outputting from a :transform is only your own output channel name, isn't it?
This is a silly test example where transform is always outputting a value for ::flow/report which will show up on the report-chan
thank you
See https://clojure.github.io/core.async/clojure.core.async.flow.html#var-map-.3Estep for reference to :transform
Hang in there and feel free to keep asking questions and offer feedback. We have a few more things planned for flow and after those ship hopefully we will get some example based usage material published.
so generally, I'd guess that ::flow/report is for reporting (as we've been discussing) -- outid is for using the auto-wired outputs in the flow (sending to listeners we're not concerned with who they are) and [pid inid] for callbacks.
I will agree that ::flow/report can be though of as centralized logging for a flow.
For the others the not concerned about what they are bit is important. A quote from the https://clojure.github.io/core.async/flow.html
> “The fundamental objective of core.async.flow is to enable a strict separation of your application logic from its topology, execution, communication, lifecycle, monitoring and error handling, all of which are provided by and centralized in, c.a.flow,”
In clojure.core.async.flow is it possible to have two branches in a flow join back up once they have completed? I have flow that forks by having two different procs :in channels connect to another procs :out channel. This is my flow definition:
{:procs
{::task/create-spreadsheet
{:proc (f/process #'create-spreadsheet)
:args {}}
::task/fetch-balance-sheet
{:proc (f/process #'fetch-balance-sheet)
:args {}}
::task/fetch-profit-and-loss-statement
{:proc (f/process #'fetch-profit-and-loss-statement)
:args {}}
::task/write-balance-sheet
{:proc (f/process #'write-balance-sheet)
:args {}}
::task/write-profit-and-loss-statement
{:proc (f/process #'write-profit-and-loss-statement)
:args {}}
::task/done
{:proc (f/process #'done)
:args {}}}
:conns [[[::task/create-spreadsheet :out] [::task/fetch-balance-sheet :in]]
[[::task/create-spreadsheet :out] [::task/fetch-profit-and-loss-statement :in]]
[[::task/fetch-balance-sheet :out] [::task/write-balance-sheet :in]]
[[::task/write-balance-sheet :out] [::task/done :balance-sheet]]
[[::task/fetch-profit-and-loss-statement :out] [::task/write-profit-and-loss-statement :in]]
[[::task/write-profit-and-loss-statement :out] [::task/done :profit-and-loss]]]}
you can use the flow/input-filter to narrow your input channel read set after reading the first one
Optionally, _any_ returned state, whether from init, transition
or transform, may contain the key ::flow/input-filter, a predicate
of cid. Only inputs (including in-ports) satisfying the predicate
will be part of the next channel read set. In the absence of this
predicate all inputs are read.so you read as normal, then return the flow/input-filter to only read from the channel you haven't heard from yet
you don't need a custom ProcLauncher
it is very tricky
basically you need to consume from either of two channels until you get something, then consume from only the one you didn't get something from
I think you can build something like that, maybe with :in-chans or whatever it's called, but would be cleaner as a custom ProcLauncher impl
@hiredman Thanks. I'll look at that.