Michal Bičan

I would like to point out an importance of this issue and come up with a solution. I see this issue as a dealbreaker. I would go as far as...

another thing to consider when designing eventStore interface is #610 dead letter queue. Ideally we should store event subscriber failure information atomically with the event published confirmation

I have been thinking. We are dealing with the Two Generals Problem ( https://en.wikipedia.org/wiki/Two_Generals'_Problem https://www.youtube.com/watch?v=IP-rGJKSZ3s ) which has been proven unsolvable. The way around it is outbox pattern https://medium.com/engineering-varo/event-driven-architecture-and-the-outbox-pattern-569e6fba7216 ....

Here is some code so we can iterate the solution. @rasmus is this the general direction you want to see this feature going to?

Different idea let's call it "EventLogAggregateRoot" - solution on a higher level of abstraction. Instead of changing low level interface IEventPersistence, let's create help EventLogAggregateRoot aggregate with events: - EventToBeCommitedEvent...

I actually don't know how to reconcile it with #606 but who knows maybe there could be two implementation of sagas. Improved version of current AggregateSaga which could handle commands...

In deed throwing an exception makes more sense. If sagas are notified of failed command in a standard way #606 then messing with commands to saga is unneccessary

My intial motivation was to create a saga by publishing a command so I don't have to have another aggregate that would start the saga. AggregateCreatedEvent -> starts saga, saga...

I was getting this error when one of the *.sol files has been compiled twice because it has been accessible from two different paths because I have had a symlink...