Panic with malformed query

Report a Dgraph Bug

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 {

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.

This looks like a fixed issue Dgraph 20.03.0 live panic: interface conversion: interface {} is nil, not int64

Can you please check what is the version of Dgraph at that latest? Sometimes we use the latest but don’t pull the really latest.

Dgraph version : v20.11.0

Dgraph codename : tchalla
Dgraph SHA-256 : 8acb886b24556691d7d74929817a4ac7d9db76bb8b77de00f44650931a16b6ac
Commit SHA-1 : c4245ad55
Commit timestamp : 2020-12-16 15:55:40 +0530
Branch : HEAD
Go version : go1.15.5
jemalloc enabled : true

So this happens during query execution? Does it happen in a new cluster? with no data.

Not sure, but I believe this should be quoted. I don’t remember GraphQL IDs being integer.

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.

Yes, but presumably the query shouldn’t cause a panic. And if it should, the message should be changed not to tell me to come file it as a bug here.

Okay, did this panic stopped the cluster?

@gja, @dmai - Can we have a human-friendly error instead of panic in this case?

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.

That is the description for the ID scalar from the generated schema by Slash. Maybe it need updated if it is not correct.

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.
1 Like

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.

Previously that was not happening and we were getting an panic because expected type for ID is string.
PR:fix(GraphQl):This PR fix a panic when we pass a single ID as a integer and expected type is [ID].We now coerce that to type array of string. by JatinDevDG · Pull Request #7325 · dgraph-io/dgraph · GitHub