When replaying a projection (using the TrackingEventProcessor), an event fails processing because of a org.axonframework.serialization.SerializationException (because of an invalid event payload; an attribute is missing in the JSON while the event class requires it).
The exception is logged and/but event processing for the same aggregate continues, ie an event ia skipped.
I know one can define default/custom error handlers or start using a DLQ.
Also the SerializationException extends AxonNonTransientException which indicates a fatal one. However this does not apply to event processing.
Just wondering why event processing (for the same aggregate) should continue instead of halting the replay of a projection.
In this case I’m referring to a TrackingEventProcessor. So it means that if we have corrupt event payload (JSON) which cannot be de-serialized then those events will be (non-silently) skipped (ie logged).
Then we need to introduce a custom exception handling or DLQ to overcome this?
Sorry, I was referring more to the work done in the event handling methods than the type of event processor.
For example if the goal is to build up a projection, missing an event will make the projection out of sync with the aggregate state. In that case, change the error handler to a PropagatingErrorHandler.instance().
If it’s important to keep processing while there might be errors on some aggregates, the DLQ might be a good option. As with the propagating error handlers, if the error is a SerializationException the event processor will be stuck for that segment, and also not process any other aggregates. While with the DLQ the message will be put in the dlq, and other aggregates can be processed as normally.
In both cases it’s important to have some monitoring, so problems can be resolved easily. Especially in the case of SerializationException it might affect a lot of aggregates. This might even fill up the DLQ to the point where further processing is stopped.
Please note with AxonIQ console provides an almost zero configuration option to be able to see the DLQ, and retry/delete DLQ items. We also use console internally, and it makes it easy to use the DLQ by default for all the event processors.