search

OrleansContrib / Orleans.Sagas

A distributed saga implementation for Orleans
MIT License
150 stars 28 forks source link

Expose execution errors of failed activities #41

Closed majdee closed 3 years ago

majdee commented 3 years ago

Hi,

As I consumer of this package, I need to know the compensation method which the failure cause.

So I thought about three approaches to handle it:

  1. Add a new property to the SagaState to store the exception that been thrown by the Execute method of activity. ( this could be also an array of exceptions, to support multiple executions of activities in parallel in the future).

  2. Add a new property to the IActivityContext to store the exception that been thrown by the Execute method of activity.

  3. Use ISagaPropertyBag to hold the exception, adding the serialized exception to the dictionary.

    In my opinion option 1 + 2 more suitable than the third one.

    What do you think?

creyke commented 3 years ago

Personally I favor option 1, as the saga state storage remains atomic and all related data is contained in a central location (with the exception of the cancellation flag stored in the SagaCancellationGrain).

Are all exceptions relevant in a parallel execution context? Or just the first logged? I would be concerned that other exceptions may be caused indirectly by the first in some cases. But storing them all shouldn't be an issue so it's probably best to do that. Maybe they could be in a Dictionary and keyed by activity id?

I'd propose some form of distributed tracing should still be hooked up as it's important to check that application insights or equivalent telemetry providers cover that off / receive these issues (so they are easy to monitor en masse).