Generic actions vs Splode errors

Ash Forum Ash Questions / Help
,
1

I’ve been using generic actions lately but when they need to return {:error, whatever} things go a bit haywire. Remembering something about Splode from the changelogs I attempted to create custom errors for my application, following the get started with splode guide.

That produces errors that seem to do the right thing, but when a generic action returns {:error, %MyApp.Errors.CustomError{...}} I get a different error.

The following reproduces it:

Mix.install(
  [
    {:ash, "~> 3.0"}
  ],
  consolidate_protocols: false
)

defmodule Accounts.Errors do
  use Splode, error_classes: [
    invalid: Accounts.Errors.Invalid,
    unknown: Accounts.Errors.Unknown,
    custom: Accounts.Errors.Custom
  ],
  unknown_error: Accounts.Errors.Unknown.Unknown
end

defmodule Accounts.Errors.Custom do
  use Splode.ErrorClass, class: :custom
end

defmodule Accounts.Errors.CustomError do
  use Splode.Error, fields: [:thing, :message], class: :custom

  def message(%{thing: thing, message: message}) do
    "Custom error for #{thing}: #{message}"
  end
end

defmodule Accounts.Profile do
  use Ash.Resource,
    domain: Accounts,
    data_layer: Ash.DataLayer.Ets

  actions do
    defaults [:read, :destroy, :create, :update]

    action :fun, :term do
      run fn _, _ ->
        {:error, Accounts.Errors.CustomError.exception(thing: "city hall", message: "really has gone to pot")}
      end
    end
  end
end

defmodule Accounts do
  use Ash.Domain, validate_config_inclusion?: false

  resources do
    resource Accounts.Profile do
      define :fun
    end
  end
end

err = Accounts.Errors.CustomError.exception(thing: "city hall", message: "gone to pot")
IO.inspect(err, label: "error at toplevel")

IO.puts("error from generic action")
Accounts.fun()

# $ elixir ash_error_issue.ex
# error at toplevel: %Accounts.Errors.CustomError{
#   thing: "city hall",
#   message: "gone to pot",
#   splode: nil,
#   bread_crumbs: [],
#   vars: [],
#   path: [],
#   stacktrace: #Splode.Stacktrace<>,
#   class: :custom
# }
# error from generic action
# ** (UndefinedFunctionError) function nil.exception/1 is undefined
#     nil.exception([errors: [%Accounts.Errors.CustomError{thing: "city hall", message: "really has gone to pot", splode: Ash.Error, bread_crumbs: [], vars: [], path: [], stacktrace: #Splode.Stacktrace<>, class: :custom}], splode: Ash.Error])
#     (ash 3.0.9) /home/.../elixir-1.16.2-erts-14.0.2/11d33faefc03b6705b27e772a36495ef/deps/splode/lib/splode.ex:211: Ash.Error.to_class/2
#     (ash 3.0.9) lib/ash/error/error.ex:66: Ash.Error.to_error_class/2
#     (ash 3.0.9) lib/ash.ex:1306: Ash.run_action/2
#     ash_error_issue.ex:64: (file)
2

Interesting…so the problem is that it’s looking for an error class to cast it to and not finding one, hence the nil. I think we could probably simplify the conversation by reproducing this in splode tests.

If, for example, your custom errors aligned with ash error classes, I think this would work just fine.

3

Not sure what you mean by aligning with ash error classes.

I thought that it already had an error class, eg:

Accounts.Errors.to_class(err)
%Accounts.Errors.Custom{
  errors: [
    %Accounts.Errors.CustomError{
      thing: "city hall",
      message: "gone to pot",
      splode: Accounts.Errors,
      bread_crumbs: [],
      vars: [],
      path: [],
      stacktrace: #Splode.Stacktrace<>,
      class: :custom
    }
  ],
  splode: Accounts.Errors,
  bread_crumbs: [],
  vars: [],
  path: [],
  stacktrace: #Splode.Stacktrace<>,
  class: :custom
}
4

Thats calling it on your own error module, not Ash’s error module. Ash doesn’t have a :custom error class.

5

I was returning an error tuple from the generic action, like {:error, :enoent} but it raised errors about not having the right arguments to construct an Ash.Errors.Unknown.Unknown or something. Figuring I know what this error is, I guess it needs a custom error so I tried adding one by copying the Splode guide but that’s not working out.
So it seems I need to either add a :custom error class to Ash’s error module, or only use an error class that’s already in Ash’s error module, or… I’m not sure what is the use of defining an error class in my app’s error module if it will be passed to Ash which rejects it.

6

Sorry, I’m not saying there isn’t a bug here. If you return {:error, :enoent} we should accept any value, and unknown values should ultimately be wrapped in an unknown error. Please open a bug in ash for that not working.

In the meantime:

You don’t need to set up your own entire Splode system to have custom errors. If you want to create your own “proper” invalid error, you’d only need to define the individual error:

defmodule MyApp.Errors.FileDoesntExist do
  use Splode.Error, fields: [:file], class: :invalid

  def message(%{file: file}) do
    "File #{file} doesn't exist."
  end
end

and then return {:error, MyApp.Errors.FileDoesntExist.exception(file: "filename")}

The bit about error classes is that there are only four error classes that Ash knows about.

:forbidden, :invalid, :framework and :unknown. Errors with a different class should be treated as :unknown, but you’re clearly having a bug where thats not happening.

1 Like
7

Also a bug if you return %YourCUstomErrorFromSomeOtherSplode{} that should also get wrapped in an UnknownError.

8

Thanks that all makes it a lot clearer. I’ll see about reproducing the original problem and raise an issue if I can.

9

Ah, it was a warning, the error tuple I was returning: {:error, {:worker_crashed, :enoent}}
And the warning:

the following fields are unknown when raising Ash.Error.Unknown.UnknownError: [value: [worker_crashed: :enoent]]. Please make sure to only give known fields when raising or redefine Ash.Error.Unknown.UnknownError.exception/1 to discard unknown fields. Future Elixir versions will raise on unknown fields given to raise/2

Thinking that this keyword list is going to be fed to the Ash.Error.Unknown.UnknownError constructor, I checked the fields it supports and tried changing that to {:error, {:error, :enoent}} but I get the same kind of warning.

Non-nested error tuples like {:error, :enoent} get wrapped in an UnknownError without warning. Seems it just doesn’t like nested tuples - is that worth raising as an issue?

As for the custom error case, when I change the error_class to :framework then it gets wrapped in an Ash.Error.framework{} which looks like its working.

10

Yeah, that looks like a mistake on our part. We are saying UnknownError.exception(value: ...) somewhere where we should be saying UnknownError.exception(message: ...). Could you open an issue w/ that on ash?

1 Like