Maybe it’s just me, but this is the 2nd time I got burned thinking flow/inject respects order. Could we add a N.B.: inject does not guarantee order. Use ::flow/in-ports and a channel for that ?
All messages sent in a single inject call are made in order (it’s a doseq of >!!). No set of unawaited independent inject calls to different target coords could ever be in an order since each proc is always async relative to the others. But since inject returns a future you can ensure order by waiting for it before proceeding. Not sure how much more control you could want.
P.S. I know the inject function specifically states “asynchronously”, but I still fell for the mental trap
Order of what? I don’t understand
I guess he means if you do :
(do
(flow/inject graph [:pid :nums-in] 1)
(flow/inject graph [:pid :nums-in] 2)
(flow/inject graph [:pid :nums-in] 3))
there is no guarantee that they will be received by :pid transform in that orderWhich makes sense from the doc string saying Asynchronously but I guess people can misuse inject with code like (doseq [m msgs] (flow/inject ... m)) to push a bunch of messages into a graph and be confused with the result
Yes. This is exactly what I mean. Sorry if it wasn't clear
So even injections to the same [pid in-id] may be processed out of order?
Yes. Each injection is put on a thread pool to be executed
I don’t know, that’s what “asynchronously” means?
maybe adding to the doc string a warning like "Since inject is async it shouldn't be used to inject a sequence of messages if their order matters, use flow/in-ports instead"?
Maybe it's just me, but wouldn't flow/infect be an invaluable edition to any API? I don't really care what it does -- maybe make a server explode somewhere?