Sending enum-arguments as variables (with Relay) mostly results in VariableTypeMismatch

This issue is a bit related to the question and answer on http://stackoverflow.com/questions/35946313/how-to-set-a-relay-variable-as-an-enum-value/35987582#35987582, however my issue is specifically server-side.

I have these relevant parts of the schema for Users:

Users(orderBy: [UserOrdering]): UserConnection

input UserOrdering {
  sort: UserSortField!
  direction: SortDirection!
}

enum UserSortField {
  FIRSTNAME
  LASTNAME
  FULLNAME
}

enum SortDirection {
  ASC
  DESC
}

When sending the query with orderBy specified as a variable:

query($orderBy: [UserOrdering]!) {
  viewer {
    ...on LoggedInViewer {
      Users(orderBy:$orderBy) {
        edges {
          node {
            fullName
          }
        }
      }
    }
  }
}

variables:
{
  "orderBy": [{"sort": "FULLNAME", "direction": "ASC"}]
}

Most of the times I get back: Validation error of type VariableTypeMismatch: Variable type doesn't match.

When sending orderBy hardcoded, the query always works:

query {
  viewer {
    ...on LoggedInViewer {
      Users(orderBy: [{sort:FULLNAME, direction:ASC}]) {
        edges {
          node {
            fullName
          }
        }
      }
    }
  }
}

---

Now, the strange thing is that sometimes querying with orderBy as a variable works (when sending the query with GraphiQL a couple of times). I suspect it has something to do with the order of execution on the server-side, but I’m not sure what to look for exactly.

Can you help me making this query work consistently?

NB: I’m using version 2016-09-02T14-27-54 of graphql-java

[dminkovsky]

Ahhh thank you @TomerSabags. This makes sense… so we can add VariableTypeMismatch to the list of rules that depend on == for validation (#85).

[fibbers]

After debugging this a bit futher, I now see when the error is thrown.

Some debugging notes about the variables when evaluating VariableTypesMatchRule.checkVariable:

• this results in the error:

  variableReference: VariableReference{name='orderBy'}
  variableDefinition: VariableDefinition{name='orderBy', type=NonNullType{type=ListType{type=TypeName{name='UserOrdering'}}}, defaultValue=null}
  variableType: GraphQLNonNull{wrappedType=graphql.schema.GraphQLList@259b9b2e}
    wrappedType: graphql.schema.GraphQLList@259b9b2e
      wrappedType: graphql.schema.GraphQLInputObjectType@259b9b2e
        name: “UserOrdering”
  inputType: graphql.schema.GraphQLList@37d2f318
    wrappedType: graphql.schema.GraphQLInputObjectType@37d2f318
      name: “UserOrdering”
  

• this results in a succesful response:

  variableReference: VariableReference{name='orderBy'}
  variableDefinition: VariableDefinition{name='orderBy', type=NonNullType{type=ListType{type=TypeName{name='UserOrdering'}}}, defaultValue=null}
  variableType: GraphQLNonNull{wrappedType=graphql.schema.GraphQLList@5cb3019a}
    wrappedType: graphql.schema.GraphQLList@5cb3019a
      wrappedType: graphql.schema.GraphQLInputObjectType@5cb3019a
        name: “UserOrdering”
  inputType: graphql.schema.GraphQLList@5cb3019a
    wrappedType: graphql.schema.GraphQLInputObjectType@5cb3019a
      name: “UserOrdering”
  

Now, let’s find out why variableType.wrappedType sometimes refers to a different object than inputType (which causes VariablesTypesMatcher to error).