Check scalar arguments when building the schema

[oryan-block]

Fixes #859

Checklist

• Pull requests follows the contribution guide
• New or modified functionality is covered by tests

Description

MethodFieldResolver passes an argument straight to the resolver only if the value already fits the parameter class and the argument is a scalar other than ID. Otherwise it converts it with Jackson. To know if the argument is a scalar, it looked the type name up in environment.graphQLSchema, for every argument on every call.

Now SchemaClassScanner passes the scalar names (spec scalars + scalar definitions in the SDL) through FieldResolverScanner to MethodFieldResolver, and createDataFetcher decides once per argument. The data fetchers don't read the schema anymore, so the environments in MethodFieldResolverDataFetcherTest no longer need the schema #849 gave them.

The answer stays the same: an argument type has to be a spec scalar or be defined in the SDL, otherwise TypeClassMatcher rejects it at build. Every scalar in the built schema comes from one of those two. About the SchemaTransformer question in the issue, the runtime lookup would only give a different answer if something replaced a scalar with a non-scalar type of the same name after the build. I can't think of a reason anyone would do that.

---

Also fixed the list case while I was in there (slice 2 of the resolver type cleanup, no issue). Each list level checked the outer parameter type instead of its element type. So this built:

type Query {
    count(tags: [[String]]): Int
}

fun count(tags: List<Set<String>>) = tags.sumOf { it.size }

But the list of lists was passed through unconverted, and every call failed with:

class java.util.ArrayList cannot be cast to class java.util.Set

Now each level checks its element type, so Jackson converts the inner lists to sets. List<List<String>> is still passed through like before. One side effect is that List<Collection<String>> now goes through Jackson instead of being passed through, with the same values. Raw List parameters can't hit this because they already fail at build ("generic type information was lost").

Release note: a nested list argument for a parameter with a non-List inner collection, e.g. [[String]] for List<Set<String>>, is now converted instead of failing with a ClassCastException.

Added a MethodFieldResolverTest case for nested sets of String and of a custom scalar. Both failed with the ClassCastException before the fix. mvn clean verify passes on JDK 25, against graphql-java 26.1 and 25.1.

Also checked through the public API with a custom scalar Jackson can't build (Tag and [Tag!]!), ID into a Long parameter, and [[String!]!]! into List<Set<String>> and List<List<String>>. On master the nested sets query fails with the ClassCastException and the other three return the same results as on this branch. On this branch all four work, also with graphql-java 25.1 at runtime.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud