Replies: 1 comment 1 reply
-
This is technically bad advice, but I don't shy away from writing a migration that fixes old events if they were caused by a bug in the past. I don't want a but that lasted a few days to be something I have to deal with in code for the next 10 years. Migrating old events is risky but gets rid of the problem for good. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi everyone,
I've been working with Laravel Event Sourcing and have encountered a challenge that I'd appreciate some advice
I initially implemented Events and Projectors for updating account balances. This setup has worked well for several months, updating balances several times a day. My setup includes:
However, I've run into an issue where some events registered unusually high balances due to a bug. I've fixed the bug, but it left some historical data incorrect. When replaying events for all projectors, or only new ones, it results in inaccurate historical points.
I've read about Compensation Events and Retroactive Events as potential solutions. But when I tried implementing these, I couldn't properly trigger a new event/projector inside my normal projectors. It also seemed like bad practice to add a conditional in every affected projector. I'm concerned about the sustainability of this approach as future errors might arise.
Could anyone advise on the recommended process to handle such a scenario in Laravel Event Sourcing? Is there a more efficient way to correct historical data without compromising the integrity of the event log?
For now I'm just doing a skip of the actions if it encounter a bad scenario but I feel is not the best approach which I consider safe because I will keep all the events untouched.
Thank you in advance for your insights!
Beta Was this translation helpful? Give feedback.
All reactions