UNORDERED

Keeps all previous execution of the DSL block running. Whichever DSL block result is first is the first to execute also ChangeState. In other words, the order of execution is not guaranteed at all.

Example: Let's assume we have the following DSL definition and dispatch two times very short after each other Action1.

var invocations = 0

inState<SomeState> {
 on<Action1>(executionPolicy = UNORDERED) { action, stateSnapshot ->
     invocations++
     delay( 1000/invocations )
     OverrideState(...)
     }
}

By applying UNORDERED policy then there are no guarantees that dispatching two times Action1 will result in the same order calling OverrideState. In the example above the delay decreases with each Action1 execution. That means that for example the second dispatching of Action1 actually return OverrideState() before the OverrideState caused by the first dispatching of Action1.

With UNORDERED this is explicitly permitted.

If you need guarantees that first dispatching of Action1 means also corresponding OverrideState should be executed in the same order as Action being dispatched, then you need ORDERED as ExecutionPolicy.

(uses flatMapMerge under the hood)