You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Results in an indeterministic order when :cmp/Y receives commands. Here's what I learned:
after the handler returns :emit-msg with tho messages, systems-toolbox invokes a/put! in order, i.e. :cmd/a will be put!'d before :cmd/b. So this is fine.
however the a/<! in msg-handler-loop will be sometimes delivered out of order.
I realise it appears to be outside of scope/control of systems-toolbox, however I decided to raise this issue for two reasons:
It seems that guaranteed order of delivery would be a useful feature.
:emit-msg accepts a vector, which is an ordered collection, so it's natural to think this order will be respected. If it's not a bug and it's an expected behaviour that order isn't guaranteed, maybe all the examples, and maybe even some assert, should make it extra clear that i.e. a set should be used, not a vector?
Is order of messages coming out from a single :emit-msg to the single destination, supposed to be preserved?
EDIT: all that happens in ClojureScript. Not sure whether it's reproducible in Clojure too.
To shed some more light on why it's important in my use case to have those messages ordered: I have a component that has the job of reordering incoming backend responses in a preconfigured way, to ensure that the rest of the system works well.
I.e. imagine that your app expects to receive a list of people, where each person has a :country-id N, and a list of countries like [{:country-id N :country-name "Japan"} ...]. In my handler for the list of people, I'd like to always already have a list of countries, so that I can assume I will always be able to enrich each person map with :country-name. I don't want to worry about not having a list of countries at hand in the people handler, to keep it simple. I have no control over the order of messages coming from the backend either. So I created this coordination component that was supposed to do the job.
Cheers!
Kamil
The text was updated successfully, but these errors were encountered:
Hi @kamituel, sorry, I just see this, don't remember ever getting a notification for this. Anyway, this behavior is odd, I would have expected messages being received in order. I will investigate and get back to you. Cheers
Hi @matthiasn!
It got me by surprise yesterday when I learned that doing this in one component (
:cmp/X
):In a system where this is specified:
Results in an indeterministic order when
:cmp/Y
receives commands. Here's what I learned::emit-msg
with tho messages, systems-toolbox invokesa/put!
in order, i.e.:cmd/a
will beput!
'd before:cmd/b
. So this is fine.a/<!
inmsg-handler-loop
will be sometimes delivered out of order.I realise it appears to be outside of scope/control of systems-toolbox, however I decided to raise this issue for two reasons:
:emit-msg
accepts a vector, which is an ordered collection, so it's natural to think this order will be respected. If it's not a bug and it's an expected behaviour that order isn't guaranteed, maybe all the examples, and maybe even someassert
, should make it extra clear that i.e. a set should be used, not a vector?Is order of messages coming out from a single
:emit-msg
to the single destination, supposed to be preserved?EDIT: all that happens in ClojureScript. Not sure whether it's reproducible in Clojure too.
To shed some more light on why it's important in my use case to have those messages ordered: I have a component that has the job of reordering incoming backend responses in a preconfigured way, to ensure that the rest of the system works well.
I.e. imagine that your app expects to receive a list of people, where each person has a
:country-id N
, and a list of countries like[{:country-id N :country-name "Japan"} ...]
. In my handler for the list of people, I'd like to always already have a list of countries, so that I can assume I will always be able to enrich each person map with:country-name
. I don't want to worry about not having a list of countries at hand in the people handler, to keep it simple. I have no control over the order of messages coming from the backend either. So I created this coordination component that was supposed to do the job.Cheers!
Kamil
The text was updated successfully, but these errors were encountered: