-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
object validation creates misleading non null error #1989
Comments
any progress on this? |
Hello, guys I can't find the solution to the bug. |
Any recommendations on how to debug this if it is happening and figure out the actual error? |
@timbrownsf Yeah, |
this one works well So for myself i think there is an issue on handling exceptions in case the second query above fails, as compared to the first query above that whether find or fail. so am continuing digging up whether i will get the solution of it.. |
That is really annoying, very hard to trace errors. I see something like this a good remedyhttps://github.com//pull/402 |
Any updates on this one? |
apollographql/apollo-client#4180 (comment), this reply helped solve the issue |
I bypass the problem using JSON.parse and JSON.stringify like this. @Query(returns => Film, { nullable: false })
async film(
@Arg("episode_id")
episode_id: number
) {
let film = await FilmsModel.findOne({episode_id:episode_id});
return JSON.parse(JSON.stringify(film)) ;
} |
Didn't work. Any other work-around? I tried using |
@vipiny35 Not sure if your problem is the same, but if you want to access sub-objects functions you have to do something like this:
You would expect "game" to be the Document from mongoose here, however in the FieldResolver it is some flat data objet, not a class anymore. |
@mschipperheyn Can you provide a reproducible example? (3 years later!!!) For posterity: when we bubble up nulls, the original error is still supposed to be included in the errors array for this exact purpose. So this problem at first glance seems surprising. I may have misunderstood, of course! |
Closing this old issue. Feel free to reopen as necessary. |
What is happening
A non null error is reported for a field that is not null, e.g.
Cannot return null for non-nullable field Account.id.
What is really happening
When you dig into graphql code and start console.logging intermediate results, you start seeing very different things:
Scenario 1
Expected a value of type "PostRegistration" but received: "TERMS"
So, in this case, I had added a value to an ENUM field in the database but forgot to add it to the graphql enum, hence the error. Impossible to determine from the provided error message (
cannot return null ...
).Scenario 2
non nullable field Account.foo was null
In this case, another required key on the same object was provided with a null value. It seems obvious, but the error message is so specific, that you can easily miss this.
In short, a whole class of field validation errors, is being aggregated to a single highly specific message that is plain wrong.
The text was updated successfully, but these errors were encountered: