Axon Server, or Axon Framework for that matter, does not guarantee that the commands you dispatch are handled on the receiving end in the exact same order you’ve dispatched them.
From a Framework perspective, this can occur as the sending side typically does not know who’s gonna handle the commands.
It might be a Command Handling Service, an Aggregate, or several Aggregates.
Additionally, the local CommandBus you’d use can impose changes to the ordering as well.
The SimpleCommandBus will wait with dispatching the second command until handling the first was resolved.
The AsynchronousCommandBus however spins up new threads for every command you get; you’re thus completely uncoupled from any ordering constraints due to asynchronicity.
Axon Server also does not provide any guarantees in this scenario.
The parts I’ve explained above regarding the framework, also holds with Axon Server in the loop.
Additionally though, the number of services can impose changes too.
Another thing which to take into account is the Routing Strategy used of your commands when having a distributed solution for handling commands.
All these fine grained points make it quite hard for me to deduce where the exact issue lies in this scenario…
Luckily, I have quite a simple suggestion for you to ensure the ordering, from the dispatching side of things.
The CommandBus interface will, after you’ve dispatched a command, return you with a CompletableFuture.
You can simply use the
andThen() function on the CompletableFuture to issue the second command.
The CompletableFuture returned from dispatching the second command can then be waited on to publish the third.
Doing so will still make your dispatching service asynchronous, as the CompletableFuture will work on it’s own.
I hope this gives you some insights Konrad.
Feel free to reach out again if things are unclear.