Skipping events deserialization if they does not exist anymore

Axon Framework
#1

I have a situation, where we introduced new event and then released application. Unfortunately we need to rollback this application version so it means that we need to get rid completely of that newly introduced event (we removed that class from our app). Some of the customer used that event and it has been serialized to event store. Now, when applying new events on aggregate, deserialization fails, because java class does not exists anymore.

I would like to know if there is a way to ignore unknown events. There is option in XStream to ignoreElements however this option as i see ignore only fields, not whole classes. I was thinking if upcasting could do that job for me, but not sure how it can be achieved in code. Does anyone had similiar experience ? I need to add that i’m using default XStreamSerializer, nad using old 3.0.x axon framework version

#2

You that event was a mistake or created a mistake why not remove from event store?

I think you have two options here :

  1. Keep the event in your code base to handle the events present in your event store (no data loss)
  2. Remove the event from your code and also remove the records in your event store

I would choose the option 2 because who want to keep garbage in production ?

BTW: the goal of a upcaster is to transform an old event version into new one, meaning add, remove or transform event data.

#3

Thanks for answer. Is it possible to safely remove events from event store ? What i’m afraid is to do any data manipulation on production database directly. Especially where many rows will be affected. Or there is another way to do that ?

This event was mistake, because it was bad design. It was completely not necessary to introduce it. It even caused some side effect, so we decided to remove it.

#4

This blog post explains how to deprecate an event by upcasting it to an empty list: Deprecating domain events in Axon - {code that works} by Sadique Ali

2 Likes
#5

Hi @ampartumpur!

While I really appreciate the contribution brought by @Faik_Siddiqi, if I were you and just a few of records I would prefer to clean my event store up.

The scenario proposed in the link is a depreciation of a business process so it might have dozen of hundreds events that have performed some valid business flow, in you case you mentioned it was a mistake so I tend to think you have just a few of events.

But I think now you have some options to evaluate e apply, discuss with your team and take the decision that works better for you.

#6

Thanks for answers ! :slight_smile: Thing is, that we needed to rollback something quickly and effectively. Unfortunately it happens quite often. Then we are hotfixing something (not necessarily related to axon event) but during that time we have this events in db. Really often fixes are also quick, so we don’t want to remove such events.

We finally decided to other solution. I wrote custom stream upcaster and i’m filtering out events for classes which doesn’t exists. It is not best in performance however we made easily to switch on/off. So in case of rollback, we just turn upcaster on (thanks to that events which doesn’t have appriopriate class are ommited) and just after hotfix, we turn it off (then those events again will be available)

1 Like
#7

Writing a filtering Upcaster would be my recommendation as well. Happy to hear you and your team came to the same conclusion! It offers the most flexibility and is easiest to add classes too. Furthermore, you do not preemptively clear out events you might still need later on. It would be nice if Axon would provide a filtering instance out of the box…something to work on from our end, I think.