Sync command dispatch about commanded HOT 8 CLOSED

@florish Allowing dispatch with strong or eventual consistency allows the consumer to dictate their consistency requirements. Typically commands dispatched by event handlers or process managers can always run with eventual consistency since they are "background" tasks. In this scenario there's no need to incur the overhead of collecting & waiting for the strongly consistent event handlers.

from commanded.

@astery By using dispatch with consistency :strongit would wait until the strongly consistent event handlers have processed all events created by the command being dispatched. The events for a single aggregate are persisted as a batch. So in your create user command example, the dispatch would block until all three events have been handled (user created, role granted x 2).

from commanded.

@slashdotdash Great write-up! This looks like a great addition to commanded, which for me personally would solve some eventual consistency issues I'm currently encountering in test suite runs.

Some feedback:

(1) The method name dispatch_sync does not really connect me to consistency: strong on first read. I'm not sure I have a better name... dispatch_with_strong_consistency doesn't really sound like an improvement to me, but it does point a little bit more to what the method does. Maybe only offering the consistency: strong option to dispatch is OK for now, without adding a new method?

(2) I'm not sure whether the addition of :consistency on the read side is the right approach. Is it always possible to say this in an Event Handler, or does this depend on the context from where the command is being dispatched? E.g. for a specific case, a CreateBlogpost command dispatch may want to wait for a BlogPost read model projection to be updated, but in other cases, maybe not. And maybe sometimes, you do want to wait for an e-mail to have been sent, but in other cases not.

An alternative could be to add a list of event handlers to wait for on command dispatch. Example:

:ok = Router.dispatch(%CreateArticle{...}, consistency: :strong, wait_for: [ArticleProjector])
# or only with :wait_for (consistency: :strong is assumed then)
:ok = Router.dispatch(%CreateArticle{...}, wait_for: [ArticleProjector])

(3) In the current approach, it's not entirely clear to me what happens if only dispatch(consistency: :strong) is used, without adding the same option to any event handlers. Does commanded default to waiting for all event handlers, or does it default to none? That's just a decision to make, I guess, there's no absolute right or wrong here.

The above are just some ideas, the original proposal would be great in itself without any changes!

from commanded.

@slashdotdash Additional thought on (3): if the event handlers ultimately decide whether or not strong consistency is enforced, do we actually need a dispatch_sync and/or dispatch(consistency: :strong) option? I guess not.

This still leaves point (2) above open for discussion: in practice, is it a good idea to have Event Handlers have the final say in this, or should this better be handled on dispatch?

from commanded.

@florish Think I agree with you that adding dispatch_sync is unnecessary with the consistency option for dispatch. I've removed it from the proposal.

Dispatching a command with :strong consistency, but no handlers configured for the option, would wait for none (same as existing behaviour or using eventual consistency). Which needs to be stated in the documentation.

from commanded.

@slashdotdash, I agree with @florish projections should not care whenever they used for strong consistency or not. It's should be decided when we dispatch command.

from commanded.

Also I want to discuss about a more complex case when we need to wait multiple projections of same kind after dispatching a command.

For example I have a command %CreateOrder{items: [item_uuid1, item_uuid2]}, and I want to wait until both projections from list will be ready %OrderItemProjection{id: item_uuid1} and %OrderItemProjection{id: item_uuid2}

Or similar, I have a %CreateUser{roles: [%Customer{}, %Passenger{}]}, this command emits three events: UserCreated, RoleGranted, RoleGranted, so my projection updates three times.

I think something like:

dispatch(%CreateOrder{items: [item_uuid1, item_uuid2]}, wait_for: [%OrderItemProjectionUpdated{id: item_uuid1}, %OrderItemProjectionUpdated{id: item_uuid2}])`
dispatch(%CreateUser{id: user_id, roles: [%Customer{}, %Passenger{}]}, wait_for: [%UserProjectionUpdated{id: user_id}, %UserProjectionUpdated{id: user_id}]), %UserProjectionUpdated{id: user_id}])]`

Can be helpful, but it's more complex, and in such cases you maybe prefer more refined control on events order and error output.

from commanded.

This gist of CreateUserSync maybe can be some kind helpful.

from commanded.