Open atomkirk opened 3 years ago
Thanks! So I've sort of reproduced this in https://github.com/absinthe-graphql/absinthe/pull/1072, but if you look at the test failure the data
field is actually doing the right thing already today. It's missing the error message, which is bad, but I'm not reproducing the behavior you're seeing.
Can you create a reproduceable example?
Here is a minimal example where I was able to reproduce the issue:
Run elixir server.ex
and it will spin up the server and make the http request and try to match against the expected result.
I went through all sorts of schema permutations, and I believe the issue is when your resolver matches the following criteria:
non_null(list_of(:type))
query { topLevel { nestedField } }
async()
helperThe above example has a schema more or less like this:
type Todo {
id: ID!
}
type Wrapper {
todos: [Todo]!
}
type Query {
wrapper: Wrapper
}
And this query is made:
query {
wrapper {
todos {
id
}
}
}
When the wrapper > todos
resolver returns an error asynchronously, then I would expect the response to look something like this:
{
"data": {
"wrapper": null
},
"errors": [{}]
}
But instead we get:
{
"data": {
"wrapper": {
"todos": null
}
},
"errors": [{}]
}
Environment
Expected behavior
It should have propogated
null
up to the next highest nullable fieldActual behavior
the resulting payload was:
So the spec says, as I'm sure you know:
So, it works correctly if it the field wasn't a non_null, but since its non_null, it should have propagated upward