Commanded aggregate state is different than projection

rathoud96 · October 7, 2022, 9:27am

I am working with commanded by @slashdotdash. Recently I encountered an issue where my aggregate’s state was different than my projection.
For example the aggregate state is %Aggregate.Example{is_valid: false} and my projection is %Projection.Example{is_valid: true}
Now I am stuck on how to sync them or is there a way the state can be updated?

Thanks

tcoopman · October 7, 2022, 10:06am

I’m lacking a bit of context to give a good response.

Do you mean your projection in production has a bug so that it’s state is wrong? Did you forget to handle an event? Or something else?

If it’s a bug in your projection, the default way to solve this would be to fix the bug, deploy it and then replay the eventstream.

rathoud96 · October 7, 2022, 11:05am

Hello, @tcoopman thanks for the quick response.
My projection is correct but my aggregate state is incorrect.

tcoopman · October 7, 2022, 12:44pm

Do you know why they have a different internal state? Did you find the bug?

In event sourced systems your aggragate is the thing that makes decisions.
Syncing is not something we want to do manually. We always look at the stream of events. They are the source of truth.

Depending on the kind of bug you made, you can either rebuild the aggregate state:

github.com

commanded/commanded/blob/master/guides/Aggregates.md#rebuilding-an-aggregate-snapshot

# Aggregates

Build your aggregates using standard Elixir modules and functions, with structs to hold state. There is no external dependency requirement.

An aggregate is comprised of its state, public command functions, and state mutators.

In a CQRS application all state must be derived from the published domain events. This prevents tight coupling between aggregate instances, such as querying for their state, and ensures their state isn't exposed.

If an aggregate needs data owned by another aggregate, then you should lookup the data from a projection and include it in the command before dispatch. Usually this would be a projection into a read model built for querying. You can use Commanded Ecto projections to project events into a SQL database.

## Aggregate state

Use the `defstruct` keyword to define the aggregate state and fields.

```elixir
defmodule ExampleAggregate do
  defstruct [:uuid, :name]
end
```

This file has been truncated. show original

Or send in a compensating command to the aggregate. That means you need to implement that on the aggregate, and then make sure that it uses the command to fix it’s internal state.

rathoud96 · October 7, 2022, 4:20pm

I could not find the bug. In the event stream as well i just have error logs but those aren’t helpful.
I tried to delete the event stream but now if i run the same command again it says command_uuid not found.
I am pretty new with commanded that’s why having difficulty figuring out the issue.

tcoopman · October 7, 2022, 7:31pm

Do you have some code that you can share so we can take a look at it?

rathoud96 · October 11, 2022, 6:44am

It would be difficult to share the sample code, but I will try to explain in a more detail.
I have a table ‘books’. It looks something like this

%MyApp.Projection.Book{name: "My book", is_published: true}

And my aggregate looks looking like this

%MyApp.Aggregate.Book{name: "My book", is_published: false}

Now before the recent change, the is_published was true for aggregate as well but now after I put a validation for the author_id it’s giving me the wrong state in aggregate.

What the validation is
if author_id is in DB then the 'is_published: true' else 'is_published: false'

And the above validation would work only when we insert or update the operation.
Now I am not getting why this validation would change the aggregate state.
After adding the validation I didn’t do any insert or update.

tcoopman · October 11, 2022, 5:51pm

On my phone, so I’ll do my best to respond.

I’m going to take a step back from commanded and talk about event sourcing in general for a moment.

In event sourcing an aggregate takes a list of events (it’s own history) and a command and it makes a decision. That decision is communicated by returning one or more events.
The aggregate should be pure. Meaning it should make the decision only based on the information in the history of the events and the command. It should do no queries or other side effects to make a decision.

I write should. I mean I strongly suggest doing it that way. It will give you easier to understand code. Easier to test code,…

Looking at your code it looks like you’re doing a query in the aggregate. From a design perspective I would try to extract that.
It’s not clear though where you’re doing the query in the aggregate. Is it when making the decision? So where you handle the command? Or is it in the apply function?

If it’s in the apply function it is definitely wrong. Your apply function MUST be pure.

If it’s in the code making a decision. The only thing I can imply is that at the time of the command the author was not in the DB. I would expect a different event though depending on if the author is in or not, so the projection should follow and have the same information.

Hopefully this makes sense. If not let me know.