Allows replayStatus to be checked in event handlers

[macsux]

No description provided.

[dasiths]

Hi @macsux,
Do you mind giving a quick rundown of a scenario where this would be useful? Are you doing any external (api/io) calls from the internal event handler?

[macsux]

Yes, this is more towards a saga implementation where i need to confirm state of the recovery during replay, especially for last event as I'm not sure where it left off so need to do additional queries for it. I actually extended this more to add third state, replaylast which tells you that you are applying last event in recovery process. Alternative way is to have some kind of callback handler for before and after recovery to examine the state of the saga and determine where the last event processing left off as it could have triggered additional commands that never completed.

…

On Mon., Apr. 29, 2019, 9:42 p.m. Dasith Wijesiriwardena, < ***@***.***> wrote: Hi @macsux <https://github.com/macsux>, Do you mind giving a quick rundown of a scenario where this would be useful? Are you doing any external (api/io) calls from the internal event handler? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAINFWFETOLFQDMJJT6GG53PS6PYDANCNFSM4HJGKZOA> .

[dasiths]

I'm having a bit of trouble understanding this. Sorry. Are you using the aggregate to build the saga? I like to understand the scenario a bit better. Do you have an example I can have a look at?

With the triggering of additional commands. There is a caveat here.
Internal event handler shouldn't be creating more commands. Only external event handlers should do so. So when replaying (or loading from db) those external handler's don't get triggered at all.

[dasiths]

The ReplayStatus should not be required for internal event handlers and they shouldn't care about whether it's the replay or not. External event handlers should only be called once by the framework anyway.

If you want to implement the feature anyway I would consider an AsyncLocal<EventContext> (Inside the Aggregate) to capture this type of ambient information and act accordingly.