Repository navigation
Resolve union and interface values by the raw class of a parameterized type - #892
Merged
Merged
Conversation
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Checklist
Description
Slice 3 of the resolver type cleanup, no issue.
When a generic class backs a GraphQL type through a parameterized return type, a union or interface field returning it as a supertype can't resolve it. For example:
SchemaClassScannerkeepsBox<String>as the dictionary key forStringBox, butDictionaryTypeResolverlooks up the value's class, which is the rawBox, then its superclasses, interfaces and finally the simple name. So the parameterized key never matches and every query ofresultthrows fromexecute():For an interface (
named: Namedreturning aLabel<String> : Named) the lookup reaches the Kotlin interfaceNamedfirst, so it's anAssertExceptioninstead:It only worked when the GraphQL type name matched the class name.
Now
DictionaryTypeResolveralso maps the raw class of each parameterized entry to its type, but only when a single entry has that raw class. WithBox<String>->StringBoxandBox<Int>->IntBoxit's ambiguous, so it fails the same way as before (this isn't #186, which is one class for two GraphQL types). The map is built lazily on the first miss, so the schema build does no extra work.The raw class is tried last, only when the old name isn't an object type in the schema, and otherwise it falls back to the old
getObjectType(name) ?: throw. So every value that resolves today still gets the same type, and the other failures throw the same exception. E.g. ifBox<T>extendsParentandParentis mapped to an object type, aBoxstill resolves toParent's type. A subclass likeclass MyBox : Box<String>isn't covered, only the value's own class is looked up.Release note: a union or interface field now resolves a value of a generic class to the type its parameterized return type backs (a
Boxreturned asAnyresolves toStringBoxwhenBox<String>backsStringBox) instead of throwing.Folded the cases into
GenericObjectTypesTest.nested generic type arguments are resolvedgets a union field returning aPageand an interface field returning aHit, both failed on master.generic type arguments that are lists are not erasedgets a union over its twoEntityMatch<...>types, which still throws theTypeResolverError. The newa raw class keeps its own type when a parameterized entry shares itmaps the rawEntityMatchtoAnyEntityMatchnext toEntityMatch<String>->StringEntityMatch, and anEntityMatchstill resolves toAnyEntityMatch(it fails if the raw class lookup goes first).mvn clean verifypasses on JDK 25 against graphql-java 26.1 and 25.1 (348 tests), and on JDK 11 (347).Also checked it through the installed jar in a separate consumer project. On master the union and interface fields throw the errors above, on this branch they return
StringBoxandStringLabel, also with graphql-java 25.1 at runtime. The ambiguous version throws the same on both.javapof the changed classes is the same as 14.3.0.