Error in Project or ApplyEvent functions is not handled later on

[berk-can]

Hello there,
I want to know about how error handling is planned for error returning from Project or ApplyEvent function?

Both of them neither rollback saved command nor reprocess after some time passed or service is restarted?

What I want to achieve is:

I want to update another SQL table on every change made to readside, but I want to also handle errors that might happen while trying to save SQL table; worst scenario I should be able to rollback saved command, best scenario I want eventhorizon handler to try to Project or/and ApplyEvent again after some time if some flag (lets say eh.retryFailedEvent(true) ) is set

[maxekman]

Correct, proper and robust error handling is lacking in some parts of the toolkit. Do you have any code changes to suggest for how to do this cleanly in EH?

(And sorry for the late reply..)

[berk-can]

As far as I could think,
Events should have flag to check if they are correctly projected to readside, and that flag is updated whenever that event correctly projected to readside.
This way whenever EH is iterating old events it can see if an event failed to be projected to readside before next events are tried to be projected, also user can configure EH to check or even get errors and stop projecting events when there is faulty event in queue

I used Lagom (Microservice CQRS framework for Java/Scala) for last year and whenever some event are not projected we were getting error regarding projector is lagging behind and we couldnt project any new events, so we were forced to fix errors and then process events afterwards

[jaypee-f]

If a projector fails to apply an event to it’s projection. Put it in a DLQ. Next event or after timeout (for that aggregate) try to resend? This is only for projections? It’s the projectors problem solely?

[maxekman]

Regarding the flag on events, I don’t think it’s feasible. Events can be projected by multiple projectors and in principle the events shouldn’t care or know about who uses them, only that they are safely stored. If projections needs to be made up to date by re-projecting possible missed events they should be able to handle that themselves, and also be idempotent for old events.

[maxekman]

When the retryable event error is implemented it can be used with projectors to signal if another try should be done or not. See: #279