In trying to figure out how to construct a query properly, I caused a Panic in dgraph.
What version of Dgraph are you using?
Have you tried reproducing the issue with the latest release?
Latest, as pulled from the dgraph/dgraph docker image today.
Steps to reproduce the issue (command/config used to run Dgraph).
I executed this query:
query allStories {
queryUser(filter: {
id: 22
}) {
stories {
id
text
}
}
}
Which returned this result:
{
"errors": [
{
"message": "Internal Server Error - a panic was trapped. This indicates a bug in the GraphQL server. A stack trace was logged. Please let us know by filing an issue with the stack trace."
}
]
}
This basic schema should suffice:
type User {
id: ID!
stories: [Story] @hasInverse(field: author)
}
type Story {
id: ID!
author: User!
text: String @search(by: [fulltext])
}
Dgraph run with docker, the command was run in a Playground graphql session.
Expected behaviour and actual result.
Probably should get a helpful error message, not cause a panic.
Here’s the stack trace provided:
I couldn’t paste directly, it believed there were too many links in the trace.
It’s definitely not a well formed query, it’s just something I came across when trying things out. It’s a new cluster with <10 nodes added in (one of which had the ID 0x16, hence my attempt to see if 22 would retrieve it).
Well, I think that is the problem. The GraphQL ID in general is a string, and you have sent an integer.
So, that won’t happen for sure. 100%. This could happen in DQL queries, not GraphQL. There’s no conversion from Int to Hex in the GraphQL ID field. And it will never(as far I can tell) be as this isn’t part of GraphQL specs.
The generated schema provided the following description of the scalar for ID:
The ID scalar type represents a unique identifier, often used to refetch an object or as key for a cache. The ID type appears in a JSON response as a String; however, it is not intended to be human-readable. When expected as an input type, any string (such as "4") or integer (such as 4) input value will be accepted as an ID.
To highlight:
When expected as an input type, any string (such as “4”) or integer (such as 4) input value will be accepted as an ID
Just FYI, that is why it is causing a panic instead of a GraphQL type error. The type as int 22 is acceptable. And with some of the recent modifications I believe it also is able to accept a single int even if not wrapped in an array and the rewriting script coerces it into an array as needed.
If quoted, which means it is not an INT that you have to input, it should be converted to int by your back-end or Dgraph if there is such need. The GraphQL spec says that ID is always a string. Not sure where you have found this description.
Maybe this might work when you are using some custom ID. Even Dgraph’s UID is a string. That’s the point. He is trying to convert INT to Hex(UID). Also, GraphQL INT is 32 bits and Dgraph’s UID is 64.
This is a bug because the spec says Int should be coerced properly when supplied to an ID field. GraphQL says
When expected as an input type, any string (such as "4") or integer (such as 4) input value should be coerced to ID as appropriate for the ID formats a given GraphQL server expects. Any other input value, including float input values (such as 4.0), must raise a query error indicating an incorrect type.
Hi @boucher, the above issue has been fixed in the master branch. If the expected type is [ID] or ID and we got some other value apart from an integer then we internally convert that to [String] or String respectively.