Ash Resource Consistency Boundary vs Transactional Boundary

so you have a few options. Transactionality is built into Ash action. So using your chess game example, you might have something like this:

# on ChessGame

update :finish_game do
  change set_attribute(:complete)
  change fn changeset, _ -> 
    Ash.Changeset.after_action(changeset, fn changeset, game -> 
      # fetch players and modify their score
      # whatever happens here is transactional
    end)
  end
end

By default things that happen in hooks will be in the same transaction. You can also start your own transactions using Ash.DataLayer.transaction(resource, fn -> end)

If your resources are in the same data layer then this works exactly as you’d expect transactions to work. If you have resources across multiple data layers, a transaction for both will be opened. This makes it technically possible to achieve inconsistency if one transactions loses and the other one doesn’t due to a network error (for example). However, it makes a good effort at cross-data-layer consistency. There are usually some things to keep in mind if you are using cross data layer actions but I won’t go into that here because I don’t think that is the main thing in question

Thanks Zach,

Repeating so I understand… two options that you have suggested:

1. Using a “wrapping” resource, which would drive subsequent actions.
   • In this Chess example, it does make more sense that “ending the game” is the fundamental business change that is taking place… the player points is just a side effect action.
2. Use Ash.DataLayer.transaction(resource, fn -> end) , which would be outside of an Ash Resource action.
   • With the caveat/warning that it’s not actually 2-phase-commit across two different Repositories, rather just attempted transactions per repository.
   • But with the practice of only applying multi-action Ash Context API’s “bounded context”-- also assuming that each Ash Context API is strictly tied to a single Repository, we are safe…

There are usually some things to keep in mind if you are using cross data layer actions but I won’t go into that here because I don’t think that is the main thing in question

With that, I’m hearing that eventual consistency techniques would be required if we were to cross such data layer boundaries. And yes, I’m not wanting to go down a complicated rabbit hole of a multi-bounded-context distributed system (ala multiple project deployments)… Just looking at the scope of keeping things, hopefully,
straight forward simple: single domain, single bounded context, and single data layer.

Thanks! I’ll try those options.

You can use generic actions to use Ash.DataLayer.transaction to do arbitrary stuff in any resource.

action :name, :return_type do
  argument :foo, :string, ...
  run fn input, _ -> 
    # input.arguments.foo

    Ash.DataLayer.transaction([set, of, resources], fn -> 
       ..... do your work
    end)
  end
end

…or you can use the handy transaction? true option for generic actions

action :name, :return_type do
  transaction? true
  argument :foo, :string, ...
  run fn input, _ -> 
    # input.arguments.foo

  end
end

Ok. Looks like I just need to get my hands dirty and try things to find what’s going to work out best for my situation.

Thanks for showing these options.

My pleasure! Feel free to keep the questions coming

Hey @zachdaniel , hi ! One question about something I already bumped into some months ago but then things changed and I had no chance to look into this.

I have an UserInvitation resource that defines an :approve action:

update :approve do
  description "Approve an invitation."

  change set_attribute(:status, :approved)

  change fn changeset, _ctx ->
    Ash.Changeset.after_action(changeset, fn cs, invitation ->
      case App.Accounts.create_user(invitation.email) do
        {:ok, _} ->
          {:ok, cs}

        {:error, _} ->
          {:error, "Failed to create user"}
      end
    end)

    changeset
  end
end

The user case is: an user requires an invitation and approves it; at this point an user must be created and the invitation must be set to status: :approved. There is also a notification which sends and email outside the transaction, of course.

If I try to compile the code I see the warning about the need to set required_atomic? to true. I fix the code with such suggestion, and the after_action function simply is not executed.

What am I missing ? Thanks !

You’re not returning the changeset that has the after action hook on it you’re returning the original changeset.

Ok, right. It works now. I was somehow confused by the two different resources involved. Thanks