cdi event chain pattern, passing data between observers

[fra-franco1985]

In my Quarkus application, I'm using CDI events to handle domain events synchronously. I have 2 observers registered at startup, listening for the same event. I need to use the output of the first handler as input for the second handler. Is there a built-in way to achieve this with Quarkus? Or any general best practice to follow? Thanks

[quarkus-bot[bot]]

/cc @Ladicek (arc), @manovotn (arc), @mkouba (arc)

[mkouba]

In theory, you could have the event payload mutable. For sync events, all observers (with TransactionPhase.IN_PROGRESS) are notified on the same thread so you don't even need to synchronize the state. However, it might be better to declare a dedicated state holder object that is modified by the observers. Are those observers only notified when the app starts?

[Ladicek]

In addition to that, if you want the "output" of one observer to be an "input" of another observer, you need to define ordering. As in, both observers must have a @Priority defined.

[mkouba]

Obviously ;-)

[fra-franco1985]

I have implemented a solution where observers are registered during application startup and triggered when a domain event is published during business operations. Each handler can access the state modified by the previous handler, as the same domain event instance is shared among them, eliminating the need for state synchronization (as you suggested).
For now, the shared domain object contained within the event already serves as a "natural" state holder.
Currently, I use the @observes annotation on an initialization method to manually register observers on my custom reactive event bus.
This approach does not rely on standard CDI transaction mechanisms but achieves the same goal: ordering handlers by priority and executing them sequentially upon event publication.
A key advantage of this custom implementation is also that it allows me to obtain return values from handlers, which is not possible with standard CDI Events. During sequential execution, the implementation collects all handler results in a map and selectively returns the result from a specified handler, maintaining the reactive flow while providing access to specific handler outputs.
In essence, I am extending my reactive chain to include handler operations. The events I have implemented are synchronized sequentially but remain part of the overall reactive flow of my REST endpoint.
My reactive implementation may utilize different physical threads during I/O operations. However, it still guarantees sequential execution order and state visibility between handlers through Mutiny's reactive operators.

Would you recommend a better approach to achieve this result?
I really appreciate your support. Thank you!