AggregateSaga doesn't publish commands published from command handler method

[mbican]

AggregateSaga is also an aggregate so it can receive commands and even be created by a command. The problem is when in AggregateSaga command handler method I use AggregateSaga.Publish() protected method the commands are not actually published and they are lost :-(

I kind of hackishly fixed in this branch https://github.com/mbican/EventFlow/tree/EF-605_Commands_To_AggregateSaga by dispatching command through SagaStore instead of AggregateStore if I find out that command is targeted to AggregateSaga.

I suppose nicer solution can be done

[mbican]

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 and other much stricter and simpler with just a state machine as suggested in #606

[rasmus]

Not sure I would wan't to make this work, but rather throw an exception if its attempted. The aggregate saga implementation is merely the default implemented shipped with EventFlow. While the implementation could do with some cleanup and fixes, by adding this, EventFlow would depend on sagas being aggregates.

[mbican]

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

[mbican]

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 produces SagaCreatedEvent which is basically copy of the AggregateCreatedEvent. But now I think it can be better done by CreateSagaCommand emitting SagaCreatedEvent and then let the saga consume its own creation event through ISagaHandles. From there it's all nice and tidy.

Did the experiment and it crashed. I think it is a bug :-( but it is easy to fix :-) #611

If you have one command producing two events from one aggregate those events have the same sourceId. If both are delivered a single saga it is going to crash with a current implementation because the event.SourceId is being passed to saga as if the event is a command.

Anyway the idempotency for delivering events to sagas should be that one event should be delivered just once so it makes sense to use EventId as SourceId

[github-actions[bot]]

Hello there!

We hope you are doing well. We noticed that this issue has not seen any activity in the past 90 days. We consider this issue to be stale and will be closing it within the next seven days.

If you still require assistance with this issue, please feel free to reopen it or create a new issue.

Thank you for your understanding and cooperation.

Best regards, EventFlow

[github-actions[bot]]

Hello there!

This issue has been closed due to inactivity for seven days. If you believe this issue still needs attention, please feel free to open a new issue or comment on this one to request its reopening.

Thank you for your contribution to this repository.

Best regards, EventFlow