Discover unions and interfaces used only by interface fields

[oryan-block]

Fixes #597

Checklist

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

Description

A union that's only used by an interface field can't be built. Take the schema from #597: interface TestInterface { testUnion: TestUnion } is implemented by TestInterfaceImpl, which narrows the field to testUnion: TestUnion1. There's also union TestUnion = TestUnion1 | TestUnion2, and no object type returns TestUnion. Narrowing a field like that is valid GraphQL, but makeExecutableSchema() fails with Expected type 'TestUnion' to be a GraphQLOutputType, but it wasn't! and the scanner logs TestUnion as "defined but can never be accessed". Today you get around it by adding a dummy object field that returns TestUnion, or with includeUnusedTypes(true) plus dictionary entries.

SchemaClassScanner only finds types in two ways: through the fields of object types (by scanning resolver classes), and through implements. It never looks at the field definitions of interfaces. So TestUnion never gets into the scanner's dictionary, and SchemaParser.createInterfaceObject can't find it when it builds TestInterface.testUnion.

Now the discovery loop also walks the field types of every discovered interface, with list and non-null wrappers removed. Any union or interface it hasn't found yet gets added. After that, the existing loops require classes for the union's members and the interface's implementors, the same as for types reached through object fields. I left objects, enums and scalars out on purpose. An implementation can't narrow those, so if the interface has any implementor, they're already found through its class.

The new step only runs once nothing else is left to scan. Running it earlier breaks schemas that build today. Say a union member is only found by scanning another dictionary type, like Holder { image: Image } with Holder in the dictionary. Then the union-member check runs before Holder is scanned and rejects Image. Running it last keeps the discovery order the same for every type that can be reached some other way. The step is also skipped with includeUnusedTypes(true). The unused types loop already picks these unions up one at a time and scans in between. So a member that's only reachable through another member's class is still found there, and checking all members at once would break the current workaround in that case.

I added nine tests to SchemaClassScannerTest. The first six fail on master with the GraphQLOutputType error:

• the Union type in an interface-only cannot be used #597 schema, with a query through the union field
• the same schema without a class for TestUnion2
• the Interface Using a Union Fails when Implemented #382 schema
• a union on the field of a parent interface (interface NamedNode implements Node)
• a union on an interface that's only discovered later in the scan
• an interface that's only reachable through an interface field

The other three cover the ordering above. Two are for union members and interface implementors that are only found by scanning dictionary types. The third is the includeUnusedTypes workaround with a member that's only reachable through another member's class. These pass on master too and are there so the order doesn't regress.

extend interface is still broken, and I kept it out of this PR. definitionsByName and interfaceDefinitionsByName keep only the last definition with a given name, so the extension replaces the base and the built interface only has the extension's fields. That's an older bug, but it interacts with this change in one spot. With interface EItem { id: ID } and extend interface EItem { content: EContent }, master fails to build because it can't find EContent. Now it builds, but EItem has no id. It needs its own issue. Also, an interface with no implementors at all, whose field returns an object type found nowhere else, still fails in the parser. I don't think that schema is usable anyway.

#382 is the same problem with single-member unions (union Result = Node used as results: [Result!]! on interface SearchResponse). It's already closed as a duplicate of #597. The test uses its schema, plus the Query and enum definitions the issue leaves out.

Behaviour change: schemas with a union or interface used only by interface fields now build. Every member of such a union needs a class, found through resolvers or passed in the dictionary, the same as unions reached through object fields. Without one you now get Object type 'TestUnion2' is a member of a known union, but no class could be found for that type name. Please pass a class for type 'TestUnion2' in the parser's dictionary. instead of the GraphQLOutputType error. It doesn't say which union, but it names the missing type and tells you how to fix it, so I left the message alone. The dummy field workaround in #597 already needed a class for TestUnion2, so the reporter's setup should build without the dummy field now. These unions also stop showing up in the "can never be accessed" warning and in getUnusedDefinitions(). Nothing changes with includeUnusedTypes(true). Apart from the extend interface case above, I don't think any schema that built before behaves differently. The parser always failed on an interface field whose type wasn't discovered.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
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