mikesax
Ash.Error.Invalid.NoSuchInput on create
I’m starting to play with Ash, because I feel it will give me the DRYness of Rails and the clarity of Elixir & Phoenix. I roughly followed the Postgres how-to guide on the Ash framework website but I’m getting an error that I can’t explain, running this code:
Marketing.Lead
|> Ash.Changeset.for_create(:create, %{email: "mike@example.com", farmer: true})
|> Ash.create!()
This yields an error:
(elixir 1.16.2) lib/process.ex:860: Process.info/2
(ash 3.1.3) lib/ash/error/invalid/no_such_input.ex:5: Ash.Error.Invalid.NoSuchInput."exception (overridable 2)"/1
(ash 3.1.3) lib/ash/changeset/changeset.ex:2034: anonymous fn/4 in Ash.Changeset.cast_params/4
...
I suspect it has something to do with the definition of my resource. Any ideas on how to figure out what’s causing this? Thank you for your time!
defmodule Marketing.Lead do
use Ash.Resource, domain: Marketing, data_layer: AshPostgres.DataLayer
postgres do
table "leads"
repo Muck.Repo
end
actions do
defaults [:read]
create :create
end
attributes do
uuid_primary_key :id
attribute :email, :string do
allow_nil? false
end
attribute :farmer, :boolean do
allow_nil? false
default false
end
attribute :writer, :boolean do
allow_nil? false
default false
end
attribute :academic, :boolean do
allow_nil? false
default false
end
attribute :other, :string
end
end
Marked As Solved
zachdaniel
By default, an action does not accept any attributes as inputs. To resolve this, you have two options:
- Set an explicit
acceptlist. this is the simplest
create :create do
accept [:email, :farmer]
end
- Use
:*, which means all public attributes
For example:
create :create do
accept :*
end
...
attribute :email, :string do
allow_nil? false
public? true
end
attribute :farmer, :boolean do
allow_nil? false
public? true
end
This option is a bit more complex because public? affects other things like visibility over external APIs, etc.
Also Liked
zachdaniel
Yeah, I think updating the docs there is likely the best way to go, even just to indicate that we’ll be accepting things later, like
create :create do
accept []
end
instead of just create :create would help with some of the confusion. I think we want to keep it to NoSuchInput because the type of error is used by things like api extensions to show error messages, and we want to make sure that its not possible for API extensions to leak internal resource details.
but, we can add “hints” that are in the error message on NoSuchInput, like “an attribute with this name exists, but is not accepted by the action. Perhaps you need to add it to the accept list of the action?”
If you could open issues or PRs for these two improvements, that would be wonderful ![]()
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








