Skip to content
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

Argument resolver crashes when omitting a nullable input field of type list #78

Closed
ptrf opened this issue Jul 13, 2017 · 3 comments
Closed
Assignees
Labels

Comments

@ptrf
Copy link
Contributor

ptrf commented Jul 13, 2017

The schema snippets below sets the stage

input I {
     nonNull: String!
     list: [String]
}

type Mutation {
     m(input: I!): ...
}

GraphQL crashes with runtime error {case_clause, null} in graphql_execute.erl when attempting to perform this mutation:

mutation M {
  m(input: {nonNull: "non-nullable string"}) {
    ...
  }
}
@ptrf ptrf added the Bug label Jul 13, 2017
@ptrf ptrf self-assigned this Jul 13, 2017
@ptrf
Copy link
Contributor Author

ptrf commented Jul 13, 2017

If the list field of input type I has a default value, the crash doesn't happen - i.e. list: [String] = [].

@ptrf
Copy link
Contributor Author

ptrf commented Jul 13, 2017

The bug only triggers for arguments written in the query doc. The following mutation:

mutation M($input: I!) {
  m(input: $input) {
    ...
  }
}

with variables { "input": {"nonNull": "non-nullable string"} } works fine.

ptrf pushed a commit that referenced this issue Jul 13, 2017
The query doc introduces the IntroduceMonsterFatFixedInput mutation
which has the introduceMonster input object hardcoded in the for query doc.

The test case is similar to direct_input
@jlouis
Copy link
Owner

jlouis commented Jul 13, 2017

Fix merged, lets close this one.

@jlouis jlouis closed this as completed Jul 13, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants