[C-Sinclair]

A data layer that picks its connection per tenant needs the tenant in c:Ash.DataLayer.transaction/4. The reason Ash builds names the resource, the action and the actor, but not the tenant.

• Ash.DataLayer.transaction_reason/0 gains optional(:tenant) => term() on every variant that already declares optional(:data_layer_context). The key is optional, so a data layer that ignores it is unaffected.
• Ash.Changeset puts changeset.tenant on the reason in Ash.Changeset.with_hooks/3. That one site covers create, update and destroy.
• Ash.Actions.Create.Bulk, Ash.Actions.Update.Bulk and Ash.Actions.Destroy.Bulk pass opts[:tenant] at both their outer and inner transactions. Ash.Actions.Read passes query.tenant.
• Ash.Actions.Update.UpdateMany gains :tenant and :data_layer_context. It built the only reason that had neither.

The tenant sits beside :data_layer_context rather than inside it, so a data layer reads a named key instead of a convention:

def transaction(_resource, fun, _timeout, %{tenant: tenant}) do
  Repo.put_dynamic_repo(repo_for_tenant(tenant))
  Repo.transaction(fun)
end

Where this came from

ash_sqlite#224 adds strategy :context to AshSqlite, giving each tenant its own SQLite file. It carries AshSqlite.Changes.CarryTenant and AshSqlite.Transformers.CarryTenant only to put the tenant where transaction/4 can read it. @zachdaniel asked why that was necessary and suggested Ash set it in the transaction metadata. Both modules are deleted there once this lands.

With the transformer disabled, create, update, destroy, bulk_create and bulk_update all reach transaction/4 with data_layer_context: %{} and no tenant. Reads were the only path already carrying it, on query.

Not in this PR

No test asserts the new key. Of the built-in data layers only Ash.DataLayer.Mnesia implements transaction/4, and it does not read the reason, so a test needs a data layer that records what it is given. Ash.DataLayer.Ets answers false to :transact and implements neither rollback/2 nor in_transaction?/1, so wrapping it means writing a transaction implementation too. I can add such a module under test/support if you want the coverage here rather than in the data layer that consumes it.

[C-Sinclair]

We were also missing data_layer_context for Update Many, so I've added it here as well

[zachdaniel]

I think we will also need to add the tenant option to Ash.transact and Ash.transaction

  @transaction_opts_schema [
    timeout: [
      type: :timeout,
      doc: """
      The time in milliseconds (as an integer) to wait for the transaction to finish or `:infinity` to wait indefinitely.

      If not specified then default behaviour is adapter specific - for `Ecto`-based data layers it will be `15_000`.
      """
    ],
    return_notifications?: [
      type: :boolean,
      default: false,
      doc: """
      Use this if you want to manually handle sending notifications.

      If true the returned tuple will contain notifications list as the last element.

      To send notifications use `Ash.Notifier.notify(notifications)`. It sends any notifications that can be sent, and returns the rest.
      """
    ]
  ]

and thread it through.

[zachdaniel]

🚀 Thank you for your contribution! 🚀