You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Read models are updated before event handlers that implement ISubscribeSynchronousToAll #832
We publish all events to event grid using a custom class that implements ISubscribeSynchronousToAll.
I have noticed during testing that the event is not published to event grid until the read models that subscribe to that event have been updated.
Could someone confirm that this is the expected behaviour? When an aggregate emits an event, is the event handled in a synchronous manner in a pre-defined order? For example, is it something like this:
Write event to EventFlow table
Apply event to aggregate
Update read models
Publish to event grid
I'm a bit confused because I had assumed that the subscribers (read model and event grid) would run in parallel.
changed the title [-]Read models are updated before event is published event grid[/-][+]Read models are updated before event handlers that implement ISubscribeSynchronousToAll[/+]on Feb 24, 2021
Inspecting the source code I think 1. and 2. are backwards in your list
AggregateRoot.Emit() triggers application of the event to the aggregate state when it first emits. Then execution result is returned back where the AggregateStore.UpdateAsync() commits the events to the store then triggers DomainEventPublisher.PublishAsync(), which FIRST updates applicable read models and then dispatches to subscribers (Subscribers of ALL events first, then Sync subscribers, then Async Subscribers, then Sagas). If exceptions are thrown along that publishing path then execution stops. So if Read Models throw exceptions then subscribers aren't dispatched to. If SubcribersOfAllEvents results in an exception then Sync Subscribers (and beyond) are not dispatched to. Sync Subscribers will all be dispatched to (one at a time in order) if it gets to that point of publishing from the DomainEventPublisher.PublishAsync(). But if one or more Sync Subscribers throws an exception (and you turn off the default to swallow those exceptions) then that is checked at the end of the iteration and bubbled back up and publishing ceases...so the Async Subscribers are not dispatched to, or the Sagas.
Activity
[-]Read models are updated before event is published event grid[/-][+]Read models are updated before event handlers that implement ISubscribeSynchronousToAll[/+]fratting commentedon Mar 8, 2021
Inspecting the source code I think 1. and 2. are backwards in your list
AggregateRoot.Emit()triggers application of the event to the aggregate state when it first emits. Then execution result is returned back where theAggregateStore.UpdateAsync()commits the events to the store then triggersDomainEventPublisher.PublishAsync(), which FIRST updates applicable read models and then dispatches to subscribers (Subscribers of ALL events first, then Sync subscribers, then Async Subscribers, then Sagas). If exceptions are thrown along that publishing path then execution stops. So if Read Models throw exceptions then subscribers aren't dispatched to. If SubcribersOfAllEvents results in an exception then Sync Subscribers (and beyond) are not dispatched to. Sync Subscribers will all be dispatched to (one at a time in order) if it gets to that point of publishing from theDomainEventPublisher.PublishAsync(). But if one or more Sync Subscribers throws an exception (and you turn off the default to swallow those exceptions) then that is checked at the end of the iteration and bubbled back up and publishing ceases...so the Async Subscribers are not dispatched to, or the Sagas.