GeezerVison is showing github.com — Add validation to detect when datafetchers wired on interfaces · Issue #3841 · graphql-java/graphql-java
Add validation to detect when datafetchers wired on interfaces #3841
Description
A validation idea from @bbakerman
Because type wiring is registered by string name, we allow a data fetcher registration to a field in an interface type because as the time of pre schema building, we don't know its an interface. I guess with more work we could "validate" this once we have the real schema in place and we know all the types
Investigate if we can validate that datafetchers are only wired on concrete types
Potential idea
allow RuntimeWiring building as we have it day (since we have no schema elements yet)
then at "schema generation time" we validate that the values in the graphql.schema.GraphQLCodeRegistry make sense
eg data fetchers only on fields of a concrete type
type resolvers ONLY on non concrete type
all non concrete types have a type resolver
etc...
Activity
bbakerman commented on Mar 3, 2025
I had a look into this - we have some protection in place when SchemaGenerator is used (aka SDL)
We can detect that there are no type resolvers for an interface or union say..
And we kinda dont really wire in data fetchers for interface fields - you can define them but they are ignored
newTypeWiring("InterfaceType"). dataFetcher("foo", df)
The above is allowed however the SchemaGenerator code will never ask for them and hence they never make their way to the GraphqlCodeRegistry
This is only via SchemaGenerator (SDL) however - if you manually build a schema - then none of this applies and you can be missing type resolves etc...
bbakerman commented on Mar 3, 2025
I did some more digging : graphql.schema.CodeRegistryVisitor also does some checks so that type resolvers are ALWAYS present. It asserts and fails the GraphqlSchema object creation. Its not a via a InvalidSchemaException with many errors per place - just one assert
added a commit that references this issue
on Apr 3, 2026This issue will close once commit 5125b74 is merged into the 'master' branch.5125b74
Metadata
Metadata
Development
No branches or pull requestsIssue actions