boostercloud
Unexpected Event Ordering in Booster Framework
Unexpected Event Ordering in Booster Framework
Current Behavior
In the Booster Framework, when registering an array of events including [PersonCreated, ..., PersonUpdated] in a command, the order of these events seems to be arbitrarily picked. This causes errors when the reducers get called. The issue arises when all events have exactly the same createdAt property.
Expected behavior
The documentation states that for a specific entity instance, the order of events is preserved. Therefore, the expected behavior is that the order of events should be preserved as they are registered in the command.
Possible Solution
Currently, Booster uses the timestamp to build the sort key in the event store, and it adds a random string at the end to resolve potential collisions. This method works when all the events for an entity are registered from different handlers at different moments. However, this method seems to be causing issues when many events for the same entity are inserted from the same handler. This behavior could be potentially solved for events inserted by the same handler by adding to the sort key an extra sequence number after the timestamp, and before the randomized string.
A workaround to avoid this issue could be to register a single event at the end of the handler with all the data needed in the reducer instead of a series of events, or split the command handler into a series of event handlers that react to the PersonCreated event, do extra changes, and then emit the PersonUpdated and other events.
Additional information
This issue was discussed in a Discord conversation of the Booster Framework server. The conversation included users: Danno212, fyvel, and @javiertoledo .
Hey I have worked on around 7-8 company based project, but never countribute to open source, this is my first time can you assign me this task.
