Setting path on an error

Can you try this:

{:error,
  InvalidAttribute.exception(
    field: :variant_key,
    message: "feature variant not found"
   ) |> Ash.Error.set_path([:feature_override])}

We should make the path key work for all exceptions by default I think, as that is a pretty natural way to set it.

The path is being set correctly.

      {:error,
       InvalidAttribute.exception(
         field: :variant_key,
         path: [:feature_override],
         message: "feature variant not found"
       )
       |> IO.inspect()}

%Ash.Error.Changes.InvalidAttribute{
  field: :variant_key,
  message: "feature variant not found",
  private_vars: nil,
  value: nil,
  changeset: nil,
  query: nil,
  error_context: [],
  vars: [],
  path: [:feature_override],
  stacktrace: #Stacktrace<>,
  class: :invalid
}

Using Ash.Error.set_path(...) adds to the path but it’s still not in the graphql fields.

Yesterday when I was digging I thought I remember seeing builtin errors from constraints also have keys attribute: and resource: but now I can’t recreate those.

May be relevant: The argument (feature_override) is an embedded resource that has an attribute (variant_key). The update action being called is on the parent. The action appends the argument into a list of embedded resources (feature_overrides). The validation is on the parent resource because attributes of the parent affect the validation of the embedded children.

Maybe this is an issue in graphql? How is the error rendering vs how you want to? It would be a separate improvement to make the path: ... option work for ash exceptions by default, but it makes sense to do and would be easy.

The issue isn’t specific to graphql. I have similar issues in Ash Phoenix Forms. The error gets added to the changeset with the path, but something else must not be set correctly because the path gets dropped by graphql and Ash Phoenix Form too.

I’ll see if I can find a easy way to reproduce.

@zachdaniel, I hope this is a better explanation.

Given a action with an argument this is an embedded resource:

update :add_feature_override do
  argument :feature_override, Environments.FeatureOverride, allow_nil?: false
  validate {FeatureVariantExists, []}
  ...
end

And when invalid FeatureVariantExists returns:

  {:error,
    InvalidArgument.exception(
      field: :variant_key,  # this is an attribute on the FeatureOverride resource
      path: [:feature_override],
      message: "variant key not found"
    )}

And I have a form like this:

AshPhoenix.Form.for_update(socket.assigns.account, action,
    as: "account",
    api: Environments,
    forms: [auto?: true]
  )
  |> to_form()
  |> AshPhoenix.Form.add_form(:feature_override, params: feature_override_params)

When the form is invalid, the error is as expected in form.source.source.errors[] but is not in the nested form for feature_override

form.source.source.errors[
  %Ash.Error.Changes.InvalidArgument{
    field: :variant_key,
    message: "variant key not found",
    changeset: nil,
    query: nil,
    error_context: [],
    vars: [],
    path: [:feature_override],
    stacktrace: #Stacktrace<>,
    class: :invalid
  }
] 

form.forms.feature_override.source.errors = [] # I expect my error to be here on the variant_key field with no path
form.forms.feature_override.submit_errors = [] # I expect [variant_key: {"variant key not found", []}] 

When getting the error from a graphql mutation (instead of form)

%{"data" => %{"addFeatureOverrideToAccount" => %{"errors" => [%{"code" => "invalid_argument", "fields" => ["variant_key"], "message" => "variant key not found"}], "result" => nil}}}

# I expect fields to ["feature_override", "variant_key"] or even better["input", "featureOverride", "variantKey"]

So, for ash_phoenix that is definitely an issue, a reproduction test would be greatly appreciated. I can hunt down what might be going wrong. As for ash_graphql, it looks like we actually just don’t have path handling logic set up at all. It should be an addition to the existing logic. The fields is a pointer to multiple fields, not a path to the fields.

I’ll do a PR for an ash_phoenix test to reproduce this.

For ash_graphql, it’s less of an issue for me right now and I’m not sure what the conventions/specs are for errors. I personally would expect a path with camelCase.

Yeah, I agree we should add a path to the graphql errors and camelcase them

@rgraff did you manage to solve it? As i’m running into an issue where using the AshPhoenix form i’m not getting the error for a path, doing an inspect like so:

form = AshPhoenix.Form.validate(socket.assigns.form, edition_params)
IO.inspect(form, label: "____form")

the source.source.errors does contain both errors

 errors: [
        %Ash.Error.Changes.InvalidAttribute{
          field: :en,
          message: "length must be greater than or equal to %{min}",
          private_vars: nil,
          value: %{"_unused_lt" => "", "en" => "a", "lt" => ""},
          splode: nil,
          bread_crumbs: [],
          vars: [min: 2],
          path: [:title],
          stacktrace: #Splode.Stacktrace<>,
          class: :invalid
        },
        %Ash.Error.Changes.InvalidAttribute{
          field: :content_types,
          message: "must have %{min} or more items",
          private_vars: nil,
          value: [],
          splode: nil,
          bread_crumbs: [],
          vars: [min: 1],
          path: [],
          stacktrace: #Splode.Stacktrace<>,
          class: :invalid
        }
      ],

but the actual errors doesn’t contain the title.en error:

  errors: [content_types: {"must have %{min} or more items", [min: 1]}],

This is a custom ash type based on map. here’s a post with more details: