Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How about updating queries FROM the event store and not from the command handler ? #21

Closed
jrouaix opened this issue May 12, 2022 · 1 comment

Comments

@jrouaix
Copy link

jrouaix commented May 12, 2022

Hello guys

We were PoCing around your crate when found this :

for processor in &self.query_processors {

So the events are consumed to the projections from the command handler ?
What if the machine stops ?
What if the view database have issues ?
What will happen when the service restarts ?

@jrouaix jrouaix changed the title How about updating query FROM the event store and not from the command handler ? How about updating queries FROM the event store and not from the command handler ? May 12, 2022
@serverlesstechnology
Copy link
Owner

Hi @jrouaix,

You are correct that once any events are emitted from the command handler they become historical facts and are committed regardless of any query failures. This is essentially where the command phase of CQRS ends and the query phase begins. To keep the two phases decoupled, queries must manage failure conditions on their own.

For simple failure modes such as a view error you should deal with the error directly within the Query that you are using. If you are using a GenericQuery from the persist module this would entail noting the error (logs, telemetry, etc.) via an error handler in order to correct the issue.

To rectify more complex failures, a common solution is to use a field in a query to record the latest event that has been processed. Then, after a failure any query that is missing events can be identified and corrected.

A good mental model is that of these phases as two different services communicating via an event bus, and the same sort of failure recovery strategies apply.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants