Event sourced projection event is not correctly handled in complex flows

[jlabedo]

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(Agg2_id1)=>Command(Agg1_id1), 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(Agg2_id1)=>Command(Agg1_id2) 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]

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]

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]

@jlabedo currently both with @dgafka we are working on an issue around metadata propagation in #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]

This is now fixed with 1.87.0.

[unixslayer]

@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.