I understand what you want and we have considered a kind of pre-validation callback before but every time we considered it - we realised two things

• its hard to know what things needs to be validated / changed in the layer
• we already have a callback layer called the DataFetcher

So really we aim for the data fetcher to be the callback layer - graphql-java is complicated enough without need more sub specialised callbacks

There are a couple of things you can do here.

If you are building your schema from SDL (and it looks like you do) then you can use graphql.schema.idl.SchemaDirectiveWiring to wire in new data fetchers that do custom things first and the call the old data fetcher

Take a look at https://github.com/graphql-java/graphql-java-extended-validation which uses this.

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

    input Application {
        name : String @Size(min : 3, max : 100)
    }

    type Query {
        hired (applications : [Application!] @Size(max : 10)) : [Boolean]
    }

If you squint it a bit like yours - except it stops on validation errors - yours wants to change the argument values

It uses directives on fields as validation rules and introduces a wrapper data fetcher that enforces the rules. In this case it only validates. It does not modify the input args but it could

Imagine this SchemaDirectiveWiring

    @Override
    public GraphQLFieldDefinition onField(SchemaDirectiveWiringEnvironment<GraphQLFieldDefinition> env) {
        GraphQLFieldsContainer fieldsContainer = env.getFieldsContainer();
        GraphQLFieldDefinition fieldDefinition = env.getFieldDefinition();

        // you need to check the applied directives on the field args and their types to see
        // if you custom sanitizing applies - if not leave it alone
        // you will need to descend into the types of the arguments
        if (! hasYourDirectives(fieldDefinition, fieldDefinition.getArguments())) {
            return  fieldDefinition;
        }

        final DataFetcher<?> originalDF = env.getCodeRegistry().getDataFetcher(fieldsContainer, fieldDefinition);
        final DataFetcher<?> newDF = originalEnv -> {
            Map<String, Object> originalArguments = originalEnv.getArguments();
            Map<String, Object> newArguments = sanitizeArgs(originalEnv, originalArguments);

            DataFetchingEnvironment newEnv = DataFetchingEnvironmentImpl.newDataFetchingEnvironment(originalEnv).arguments(newArguments).build();
            return originalDF.get(newEnv);
        };

        env.getCodeRegistry().dataFetcher(fieldsContainer, fieldDefinition, newDF);

        return fieldDefinition;
    }

This needs to do 2 things - look at the field and its arguments the type of the arguments for your custom directives - if they are present then continue

Then this creates a new DataFetcher for the field whose job it is to sanitize the arguments and create a new DFE with those args.

It then calls the original data fetcher who is none the wiser that code aspects have been wired in.

This schema wiring happens are schema build time (once) and so the originally wired data fetcher is still called - but with different values

Let me know if this helps or you have more questions.

ps this is more a discussion than an bug so I am moving it to discussions