Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

ConstraintString type appeared in graphql schema on the client

See original GitHub issue

Issue Description

ConstraintString leaked through introspection. Is it by design? This makes GraphiQL unhappy.

Error: Invalid or incomplete schema, unknown type: ConstraintString. Ensure that a full introspection query is used in order to build a client schema.

ConstraintString can be revealed by the following query:

query Introspection { 
  __schema {
    types {
      name
      inputFields {
        type {
          name
        }
      }
    }
  }
}

Issue Analytics

State:
Created 5 years ago
Comments:34 (19 by maintainers)

Top GitHub Comments

23reactions

padenjcommented, Apr 30, 2019

I ran across this issue trying to solve a similar issue in a custom directive I created. My situation was slightly different, but I came up with a solution that could work for this issue as well. It would require an update to the directive and I’m not sure how/if it would affect non-Apollo users.

The issue is that a new type is being created in the directive schema visitor, but the type is not being added to the schema type map. For example, https://github.com/confuser/graphql-constraint-directive/blob/master/index.js#L54. If the type is not added to the schema type map, then the above mentioned error “Incomplete or Invalid schema…” will occur when Playground introspects the schema.

The following could be a possible solution. This example could be simplified since the new type is known to be either ConstraintStringType or ConstraintNumberType, but I left it a bit more generic for anyone else who might run across this issue. Note, isNamedType and isWrappingType is imported from ‘graphql’.

A possible solution could be to modify the wrapType function:

wrapType (field) {
    const fieldName = field.astNode.name.value
    if (field.type instanceof GraphQLNonNull && field.type.ofType === GraphQLString) {
      field.type = new GraphQLNonNull(new ConstraintStringType(fieldName, field.type.ofType, this.args))
    } else if (field.type === GraphQLString) {
      field.type = new ConstraintStringType(fieldName, field.type, this.args)
    } else if (field.type instanceof GraphQLNonNull && (field.type.ofType === GraphQLFloat || field.type.ofType === GraphQLInt)) {
      field.type = new GraphQLNonNull(new ConstraintNumberType(fieldName, field.type.ofType, this.args))
    } else if (field.type === GraphQLFloat || field.type === GraphQLInt) {
      field.type = new ConstraintNumberType(fieldName, field.type, this.args)
    } else {
      throw new Error(`Not a scalar type: ${field.type}`)
    }

   const typeMap = this.schema.getTypeMap();
   let type = field.type;

    if (isWrappingType(type)) {
           type = type.ofType;
    }

    if (isNamedType(type) && !typeMap[type.name]) {
          typeMap[type.name] = type;
    }
  }

11reactions

koresarcommented, Jun 25, 2018

UPD: ignore the below. The directive stopped working. 😃 UPD2: If you’d remove the two scalars below it will make the directive work, but will break client side retrospection. So, choose your destiny. 😃

I found a workaround! Omg, took a while.

Add this to your .graphql schema file (if you have one though):

# Current implementation on graphql-import does not support directives declared outside of the scehma (in node.js code).
# We have to redeclare each directive and type for now.
directive @constraint(
    # String constraints
    minLength: Int
    maxLength: Int
    startsWith: String
    endsWith: String
    notContains: String
    pattern: String
    format: String

    # Number constraints
    min: Int
    max: Int
    exclusiveMin: Int
    exclusiveMax: Int
    multipleOf: Int
) on INPUT_FIELD_DEFINITION

scalar ConstraintString

scalar ConstraintNumber