Skipping failing events when blocking segments

Is it possible to skip an event which is causing an event handler to continually retry?

I am building a replacement for a legacy system that includes decades-old information, so occasionally records include data that we couldn’t predict and haven’t coded for. In these situations, our tracking event processors can end up being blocked as they endlessly retry and event which will always fail. We don’t want to lose any events, so would like some way of putting these events into some form of separate event store or queue, allowing the system to continue processing other records while we investigate.

We are using Axon 3.4 and I can see there is the option to reset an event processor to a specific tracking token, but is it possible to set it to the next event in the segment, effectively skipping the failing event? If that is possible, once we had investigated the error and made any code changes necessary to handle to the new scenario we would then reset the processor to rerun the failing event. This would mean not interfering with the immutable nature of the event store, but may also mean needing to block a specific aggregate to ensure no other changes take place while the problem is being investigated.

I’m envisaging adding some form of admin console to our system that would get the status of the processor and allow us to stop them and call the reset methods.

Is there a way of finding the next token for this purpose, or is there some other method for dealing with problems like this?

Hi Christopher,

you can specify the expected behavior using the ListenerInvocationErrorHandler and/or the ErrorHandler. The first allows you to define what should happen when an event handler throws an exception. The second is defined on the Processor level, and allow you to define what to do when the processing of the event itself (or updating the token in the token store) failed. The latter are usually exceptions of technical nature.

The default is to log exceptions thrown by event handlers and continue processing. In case exceptions reach the ErrorHandler, the default there is to retry processing with an incremental backoff strategy (up to 1 minute).

It is technically possible to manipulate a token, but they are EventStore implementation-specific. Basically, the token that is delivered together with the failing event is the token you’d need to reset to, in order to “skip” that event. However, I’d recommend to configure a specific ErrorHandler and/or ListenerInvocationHandler to deal with these situations.

Hope this helps.