search

ecotoneframework / ecotone-dev

Ecotone Framework Development - This is Monorepo which contains all official public modules
https://docs.ecotone.tech
Other
35 stars 15 forks source link

Event sourced projection event is not correctly handled in complex flows #104

Closed jlabedo closed 1 year ago

jlabedo commented 1 year ago

Ecotone version(s) affected: 1.79.0

Description
In the context of 2 event sourced aggregates, both aggregates having projections on their stream, Then, with a synchronous flow being command (Agg1_id1)=>Event(Agg2id1)=>Command(Agg1id1), the events from Agg2 handled in its projection are not handled in the context of a projection handler, but as a "common" event handler. This breaks the projection, as the projection state is not updated and persisted, and the projection is not initialized. There is no bug in the case of different ids on Agg1: (Agg1_id1)=>Event(Agg2id1)=>Command(Agg1id2) works as expected

How to reproduce
See modified EventSourcing example in: https://github.com/jlabedo/ecotone-dev/tree/failing-es-projection/quickstart-examples/EventSourcing The example show that SagaProjection is not initialized when we create a product with Id=3

Context The case is pretty awkward, and we found it in a badly designed use case. We fixed it by redesigning correctly our aggregates

dgafka commented 1 year ago

Hey, Nice edge case :)

Can you provide PR with test case (you may copy paste your example into package/PdoEventSourcing/tests/Fixture/*) using Ecotone Lite with support for testing Event Sourced Application?

jlabedo commented 1 year ago

Hello @unixslayer, I got another use case that can be even more problematic : if the event sourced aggregate records 2 events and both events are listened by the same projection, the projection will fail in the same manner. Hope that helps, I may try to add a test for that

unixslayer commented 1 year ago

@jlabedo currently both with @dgafka we are working on an issue around metadata propagation in https://github.com/ecotoneframework/ecotone-dev/pull/134. This may be related to or have an impact on your case which I'll get back to as soon as we finish with that one.

dgafka commented 1 year ago

This is now fixed with 1.87.0.

unixslayer commented 1 year ago

@jlabedo one thing was changed in your test case during debugging. What I did was change the behavior of Saga so that it won't send a command before returning SagaStarted event. There is an additional EventHandler for SagaStarted event which will send that command. Currently, both approaches would work, but as you may see in SynchronousEventDrivenSagaTest::test_product_is_added_by_synchronous_event_driven_saga events are recorded in more predictable order where a product gets added to the basket after Saga is started. Before, the product was added before Saga gets started.