graphql-java-extended-validation: Input Validations are not working on non-nullable input object

Hi extended-validation team,

I’m facing an issue where nested input objects are not being validated by the validation jar.

I’ve done the following

Defined the directive in the SDL

directive @Size(min : Int = 0, max : Int = 2147483647, message : String = "graphql.validation.Size.message") on ARGUMENT_DEFINITION | INPUT_FIELD_DEFINITION

Defined the directive annotation against the input field

input NameRequest {
	# The title associated to the name
   	title: String @Size(min : 1, max : 1)
	# The given name
	givenName: String! @Size(min : 1, max : 1)
	# Middle Name
   	middleName: String
   	# Last Name
   	surName: String!
}

Add the SchemaDirectiveWiring

@Bean
  public SchemaDirectiveWiring initializeValidators() {
    /*
     * Can add new rules, but on default it will apply the standard set found in {@link
     * DirectiveConstraints}
     **/
    ValidationRules validationRules = ValidationRules.newValidationRules()
        .onValidationErrorStrategy(OnValidationErrorStrategy.RETURN_NULL).build();
    return new ValidationSchemaWiring(validationRules);
  }

I am using graphql-kickstart-springboot, graphql-java 14.1 and graphql-java-tools from graphql-kickstart.

What is successful is argument based validation. The following kicks off the validation

createProgram(
		#Your partner id
		partnerId: String! @Size(min: 1, max:1),
		# The program request
		programRequest: ProgramRequest!) : Program!

I saw an earlier post that nested validations were solved, but I am not seeing ValidationSchemaWiring.onField being called for Input Types.

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 2
Comments: 17 (9 by maintainers)

Commits related to this issue

Sample graphql-java-kickstart springboot GraphQL service to demonstrate issue #17 https://github.com/graphql-java/graphql-java-extended-validation/issues/17 — committed to setchy/sample-springboot-kickstarter-graphql-service by setchy 4 years ago

Most upvoted comments

I have debugged this some more. It’s more a problem (challenge) in the graphql-java library. The reason is this

In graphql-java, the type references are not filled out until the schema is built. That is UNTIL we know all possible types. Only then can we replace them.

However the SchemaGenerator makes types in a tree like fashion. It takes SDL, and starts building out types as it encounters them. It keeps a stack as it goes and if “stack” already contains the type being built (self reference in some way) then it puts in a type reference. This will later being fixed.

However as each type is built, it calls out to the “SchemaDirectiveWiring” which allows them to “transform” a given type in some way. But its doing this BEFORE the type has been truly built, each before type references are replaced.

This “early” call to SchemaDirectiveWiring is there to allow “mutation of a schema type” as its being built. However I dont think we considered type references here and how it might affect things.

I think the solution is in graphql-java and allowing the whole schema to be built AND then walk the tree of all types and allow the SchemaDirectiveWiring to be called and possible mutate a type.

This is a possible fix but not a small one.

bbakerman on Sep 21, 2020

See https://github.com/graphql-java/graphql-java-extended-validation/pull/34/files for a fix to the above

bbakerman on Oct 4, 2020

I am sadly blocked by the exact same issue… would you happen to have any “dirty fix” that can do the job until this is fixed? This make the library pretty unusable in my case, since I have global input types used across many graphqls files

With this issue only half of the query inputs get validated, and it’s only a matter of “luck” if the field is validated.

pelletier197 on Sep 29, 2020