Identify and Rerun particular events in Axon

Question

We were looking into rerunning handpicked events from axon. A use case would be along the lines of the following.

If the user's registration event failed even though the command was successful, we want to rerun that particular event for that specific event handler(s).

We looked into using the tracking event processor, but that seems to be of replaying a set of events FROM a specific point in time. However, in our case, if there were 100 events yesterday, we would only want to rerun a particular event in the middle.

At the moment we are in migration of migrating to Axon and as such have decided to go with SubscriptionEventProcessors predominantly as it is more synchronous (i.e. errors are propagated up the command handler). And we do understand that subscription processors are stateless, as in they only process what they received via the event bus.

So I am assuming that we cannot use the tracking processor? and instead, we need to load the particular event and re-push it to the event bus?

How could we achieve this? (With or without the above suggestion)

Also with regards to identifying exceptions, we are thinking of using aspects and logging and reading the particular log line for exceptions. However we did notice a tracing module for axon and spring boot. https://github.com/AxonFramework/extension-tracing However it is mentioned to be in beta and there was not much reference documents we could find yet either. Is there a better more axon based solution to this as well?

Answer 1

To be quick about it, I would use a similar response as I have posted on this question.

The rehash my response over there quickly, it can be summarized by: Create a Query Model containing the required @EventHandler annotated methods to "re-handle", which you'd provide as input to Axon's AnnotationEventHandlerAdapter constructor. You would call the subsequent AnnotationEventHandlerAdapter with a filtered event stream based on the requirements you have. As a result, the Query Model will be updated to the format you need.

Thus instead of performing it as a form of query because the users requires that information, you would perform the operation upon an exceptional case. Regardless, you will still form the Query Model anew, but just based on a specific set of events.

By the way, when it comes to the choice of Event Processor, I'd still go for the TrackingEventProcessor. Yes it means an event failure would not issue a rollback, but in essence the event states it has occurred. Thus rolling back because something else fails handling that event is incorrect; the command still succeeded, so it should stay as such too.

Lastly, you are looking for logging logic. The Tracing Extension you've shared has just recently been pulled from it's beta status and thus can be used safely. Next, basic logging can already be achieved by configuring the LoggingInterceptor as a MessageHandlerInterceptor and MessageDispatchInterceptor (documentation on this can be found here). And if you are looking to introduce Aspect logic: Axon has a similar mechanism to tie into each message handler out there. Have a look at the HandlerEnhancer/HandlerEnhancerDefintion on this page.

Hope all this helps you out @MilindaD!