I ran into an issue when executing the same query multiple times (5-10 times) in a row. Sometimes it works and sometimes it returns the follow error saying "expected a value for non-nullable variable." There are no other custom permissions for the user on the table. The user has access to all of the columns.
I did notice if I mark the id params as not required it works and returns data without an issue. Any thoughts on this one?
I'm running against version 1.0
{
"type": "http-log",
"timestamp": "2020-01-24T23:10:10.147+0000",
"level": "error",
"detail": {
"operation": {
"user_vars": {
"x-hasura-role": "admin-role",
"x-hasura-user-id": "b729b676-96b5-488e-ab12-dc045b82a846"
},
"error": {
"path": "$.variableValues.id",
"error": "expected a value for non-nullable variable",
"code": "validation-failed"
},
"request_id": "70be7e67-fab6-43b5-af00-96fc150d09d4",
"response_size": 110,
"query": {
"operationName": "ListThemeTracksByThemeId",
"query": "query ListThemeByThemeId($id: uuid! = \"9ae362ab-c094-42f0-b152-9f7914544505\") {\n\tTheme(where: {themeId: {_eq: $id}}) { \n\t\tid \n themeId\n\t\tobjectPath \n\t\t} \n}"
}
},
"http_info": {
"status": 200,
"http_version": "HTTP/1.1",
"url": "/v1/graphql",
"method": "POST",
"content_encoding": null
}
}
I created a fresh Hasura instance (v1.0 beta 2), created one table with one column and execute same query several times in the hasura console and received the same "expected a value for non-nullable variable" when passing in a required parameter. If I change the parameter to option the issue goes away.
@karice Can you see the actual network call (from Web console) and see if they are the same?
@tirumaraiselvan, yes they are the same. I was also able to reproduce in Postman.
This is an issue with the query cache - when a query's plan is cached, we don't seem to validate the variables correctly in the presence of default values for arguments.
Taking a look at this.
Simplified test case:
query:
query MyQuery ($authorId: Int! = 1) {
author(where: {id: {_eq: $authorId}}) {
name
}
}
variables: {}
Most helpful comment
This is an issue with the query cache - when a query's plan is cached, we don't seem to validate the variables correctly in the presence of default values for arguments.