GraphQL incorrect input generation

Hi folks, I've got a really weird one. AshGraphQL is generating incorrect inputs for one of my resources, and I'm completely stumped why. I've got a triple-nested embed, where the top level is PG, the rest are embeds. Component - attribute :colors -> ColorInfo ColorInfo - attribute :front -> ColorSide ColorSide - attribute :colors -> {:array, Color} Color - fields All fields in the whole chain are public, and the top level component has :* fields on the action. The read actions are generated correctly, and all fields are present and correct. The create and update actions are wrong, and the following: Component - attribute :colors -> Color It's compressed the whole chain and just accepts the deepest field, which is incorrect and won't validate when it hits the server... I can try and create a reproduction, but wanted to ask first if anybody had seen anything like it beforehand?
"A component of a print job"
type Component {
// ....

"The colors of the component"
colors: ComponentColorInfo
"A component of a print job"
type Component {
// ....

"The colors of the component"
colors: ComponentColorInfo
input CreateComponentInput {
// ...

"The colors of the component"
colors: ComponentColorsInput
input CreateComponentInput {
// ...

"The colors of the component"
colors: ComponentColorsInput
This is just the wrong input... There's zero compiler warnings, and have done a full mix clean and deps.clean. Any ideas?
5 Replies
ZachDaniel
ZachDaniel2mo ago
Do any of the embeds have a duplicated graphql type perhaps?
John M
John MOP2mo ago
Sadly not 🙁 The really weird thing is that the query side is perfect - the default read action returns the correct object graph - it's only the mutation inputs that are wrong.
ZachDaniel
ZachDaniel2mo ago
Hmmm...okay that's pretty strange, never seen that before. Can you recreate a similar setup in the ash_graphql tests and write a failing test?
John M
John MOP2mo ago
Will try 🙂 Trying to debug a bit locally too - it's not a small app, I was wondering if the scale has something to do with it. Will report back.
ZachDaniel
ZachDaniel2mo ago
It's probably not a scale thing but could be some kind of strange type generation thing with conflicting names But when that happens the error has always been a duplicate type error

Did you find this page helpful?