Commanded: Wait for an event handler based on aggregate_version

Hello @gregjohnson,

Come join us on the Elixir Slack: https://elixir-lang.slack.com/ in the commanded channel if you are looking for more timely help. There are a number of us there.

If you are wanting to wait for an event handler to catch up to a particular event, one way to do it would be to publish an event over PubSub and wait for that event before moving on.

As an example, say you want to dispatch an OrderWidget command and wait for your OrderHandler to project an OrderSummary record for a corresponding WidgetOrdered event. For the example the order is received via a REST API controller:

defmodule Foo.OrderController do
  def create(conn, order_params) do
    # listen for all order summary events
    Phoenix.PubSub.subscribe(Foo.PubSub, "order_summaries")

    # dispatch the command
    {:ok, %{aggregate_version: version}} =
      Foo.CommandedApp.dispatch(command, include_execution_result: true)

    # wait for the handler to process up to the event
    receive do
      {:order_summarized, v} when v >= version ->
        # the handler has run at least as far as we want
        # query for the summary and return a result
    after
      5000 ->
        # we've waited long enough
        # tell the caller that we accepted their order, but
        # we're having trouble... =(
    end 

    # we're done listening for events
    Phoenix.PubSub.unsubscribe(Foo.PubSub, "order_summaries")
  end
end

The handler might look something like:

defmodule Foo.OrderHandler
  use Commanded.Event.Handler,
    application: Foo.CommandedApp,
    name: "OrderHandler"

  def handle(%WidgetOrdered{} = event, metadata) do
    # write the OrderSummary record to the database
    summary = ...

    # broadcast over pubsub that we've handled this event
    Phoenix.PubSub.broadcast(Foo.PubSub, "order_summaries", {:order_summarized, metadata.stream_version})

    :ok
  end

You could use strong consistency as mentioned in the docks, but that try to avoid that where possible.

Finally, you might also try to get away with returning the input params as result: if you have successfully dispatched the command, then we know the input params were good:

defmodule Foo.AddressController do
  def update(conn, %{"id" => id, "street" => street, "city" => city}) do
    command = %ChangeAddress{address_id: id, street: street, city: city}
   :ok = Foo.CommandedApp.dispatch(command)

   # we know street and city have been accepted, so we can safely return them
   json(conn, %{address_id: id, street: street, city: city})
 end
end

Hi @drteeth,

Thanks for your commanded channel invite! … I’ll do that!

Just for completeness if anyone else comes here …

Thank for your comprehensive reply, yes, I’m familiar with the various strategies for ensuring that consistency has caught up.

Given that the commanded docs say:
“You can optionally choose to include the aggregate’s version as part of the dispatch result … This is useful when you need to wait for an event handler … ",

… my question was specifically as to how one might best use the dispatch returned aggregate version to wait for an event handler and/or any use case comparisons with the more well known strategies such as you gave in your reply.

Thanks again @drteeth …

@gregjohnson let’s chat in Slack. I’m not understanding what you are looking for, I thought that is what I showed.

@drteeth, my sincere apologies, I misread your reply. You did indeed completely answer my question. I really appreciate the time you took to provide such a comprehensive answer in the first place and I’m really sorry for wasting your time caused by my lack of proper attention to your initial reply. I’m very chastened … I’ll do better in the future …

Thanks again for referencing the slack commanded which has a lot of good stuff from people with real world implementation issues and I’ll head there in the future.

Regards …