Could not persist aggregate. I've read all the various issues around this and still have questions...

[SimonMacIntyre]

Hello, first, please forgive me for opening yet another question on this subject, I know there are many. The majority of which point to #214 as some help, but I am still left wanting to understand, as well as not satisfied really with those responses. I do not want to enable concurrency.

Consider these 2 events.

The id column has the correct order, and you can see the incorrect swap on the aggregate_version column. However, I'm very confused about how this is possible given my setup.

See, this is the pseudocode of what is causing this:

//calling code
AggregateRoot::retrieve($uuid)->actionsRetrieved($actions)->persist();

//the actionsRetrieved function
$this->recordThat(ActionsRetrieved($actions));
return $this;

//elsewhere, on a partial aggregate that is child of the above aggregate
public function onActionsRetrieved(ActionsRetrieved $a){
     $this->recordThat(new ActionsToDeliverUpdated([]));
}

The point is, I am:

• Getting the aggregate, and recording event A, then returning, and persisting
• A listener that fires onEventA fires event B, I assumed this happens synchronously because I have not enabled concurrency, and as well my setting of: 'dispatch_events_from_aggregate_roots' => false, in the config.
• If this is synchronous, and the event creation (id) column is correct, how in the world is the aggregate_version being swapped?

Am I making a mistake in my implementation here? All I want to do is have B consistently happen after A. I am recording the event myself so I'm at a loss to how B in the example above could have its aggregate_version end up being a smaller number than event A.

Hopefully this explained my issue clearly. I do not want to enable concurrency, these are supposed to be synchronous, and I thought that firing A and onEventA do EventB would always be A->B. Am I missing something here?

Thanks in advance for your time and for this great open source package! 🙏

[SimonMacIntyre]

I have gathered that it is not standard practice to apply events inside an aggregate method which is itself triggered by another event. I guess I have run into a pitfall, I thought that would be acceptable but I guess I was misusing aggregates in a way they were not designed for.

[bmbBAMBUS]

Create a reactor to handle a side effect. Example:

ActionsReactor extends Reactor {

  public function onActionsRetrieved(ActionsRetrieved $event)
  {
     $actions = ActionsAggregateRoot::retrieve($event->uuid);

     $actions
         ->GetYourPartial()
         ->updateDeliverActions([]);
         
     $actions->persist();
  }
}

//elsewhere, on a partial aggregate that is child of the above aggregate

public function updateDeliverActions(array $deliverAactions)
{
     $this->recordThat(new ActionsToDeliverUpdated($deliverActions));

     return $this;
}

[SimonMacIntyre]

@bmbBAMBUS If I used a reactor, it would not be re-applied in event replays, so that is not helpful for my use case. Likewise if I used a projector, it's possible it would work, but it's just as possible it would manifest this same way since it seems the synchronous event firing if hitting procedurally events A, B, C in order, will potentially write event C 'first' in the event persisting. Probably I'll have no choice but to implement queues to control order, that might work the way I am imagining.