Events are persisted in a different order than they are applied, causing event-sourcing to fail

In certain situations events are persistent in a different order than they are applied, caused due to the fact that these events are produces in different (nested) UnitOfWorks. This happens in the following case:

  • Command handler A produces event 1 and after that dispatches a new command that invokes command handler B
  • Command handler B produces event 2 and returns.
  • Command handler A produces event 3 after command handler B is returned.

The expected order of events in the event store is event 1, 2, 3. The actual order however is 2, 1, 3.

After further inspection it seems that the event store orders events by their global index number, generated while appending the events in the storage engine.
This conflicts with the order of the event’s sequence number which is determined when applying an event.
The solution would probably be to either order the events by their sequence number or by propagating the applied events to the current UnitOfWork’s parent, ensuring order is maintained.

I tried to illustrate this issue in a more complete example found at I am curious if this is a bug or that I’m doing something fundamentally wrong.

I failed to mention that I’m using Axon 3.0, where the inner workings of UnitOfWork are changed.

Hi Gerard,

I’ll have a look into this when I have the opportunity. Do you happen to have a small piece of code that allows me to reproduce this?



Hello Allard,

I created a unit test that shows this behavior:
In the above repository I also created a branch that shows a workaround to prevent this issue:

Kind regards,

Hi Gerard,

the issue has been reported (and addressed in the meantime):

A simplified version of your code was included as a test case in the build: