If I have an attribute in my resource that has a character that graphql doesn’t support (ex. :invalid?), then I can easily fix that by using the field_names invalid?: :is_invalid function.
Now, let’s say I have an argument to an action that has an invalid character, ex:
Ok, looking a little bit more into AshGraphQL code, I found that the argument_names is a possible function in the root graphql code block, so something like this works:
graphql do
...
argument_names search_and_create_entity: [remove_invalid?: :remove_invalid]
end
But that makes me wonder, why is this done that way? Seems a little bit counter intuitive to define that in the root layer of the graphql code block no?
I think defining that inside the action definition as shown in the above post would make it simpler and easier to find in the documentation too.
Actually, I spoke too soon, for some reason, the argument_names function works for a field like this argument :zip_4, :string
The compiler will also give a good description on how to fix it:
actions -> read -> search_and_create_entity -> argument -> zip_4:
Name zip_4 is invalid.
Due to issues in the underlying tooling with camel/snake case conversion of names that
include underscores immediately preceding integers, a different name must be provided to
use in the graphql. To do so, add a mapping in your configured argument_names, i.e
graphql do
...
argument_names search_and_create_entity: [zip_4: :zip4]
...
end
Having this argument_names search_and_create_entity: [zip_4: :zip4, remove_invalid?: :remove_invalid] will still trigger the same error:
** (Absinthe.Schema.Error) Compilation failed:
---------------------------------------
## Locations
/var/home/sezdocs/projects/rebuilt/pacman_platform/core/deps/ash_graphql/lib/resource/resource.ex:1841
Field name "remove_invalid?" has invalid characters.
Name does not match possible ~r/^[_A-Za-z][_0-9A-Za-z]*$/ regex.
> Names in GraphQL are limited to this ASCII subset of possible characters to
> support interoperation with as many other systems as possible.
Reference: https://graphql.github.io/graphql-spec/June2018/#sec-Names
yes, looks like a bug to me as well. Can you please open an issue on ash_graphql? Even better would be to modify the one of the testing resources to have the same conditions, and confirm that the bug is still hit.