Build enums used only by directives without a Java class - #852

Fixes #823

Checklist

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

Description

An enum that's only used as a directive argument fails the schema build unless you register a Java enum for it. This is the schema from the issue:

enum Purpose { SECURITY EXECUTION }

directive @link(url: String!, for: Purpose) repeatable on SCHEMA

type Query { hello: String }

SchemaClassScannerError: Enum type 'Purpose' is used in a directive, but no class could be found for that type name. Please pass a class for type 'Purpose' in the parser's dictionary.

It fails even when the directive is never applied. The common case is Fed2's @link(for: link__Purpose), where people end up writing a dummy link__Purpose enum just to get the schema to build.

SchemaClassScanner#handleDirectives scans the arguments of every directive definition and sent enums through handleDictionaryTypes, which throws when the dictionary has no class for them. SchemaParser#createEnumObject also required a Java enum for every enum. But directive argument values are never passed to resolver methods, so there's nothing for the class to be matched against.

Now the scanner handles directive enums in handleDirectiveEnum. If there's a dictionary class for the enum it's used, as before. Otherwise the enum goes into unvalidatedTypes, which nothing else puts enums in. Once scanning is done, validateAndCreateResult keeps only the enums there that no field, argument or input field of a type in the schema uses, and passes them to the parser as ScannedSchemaObjects#directiveOnlyEnums. That check includes fields added by extend type/extend input and types found through includeUnusedTypes. createEnumObject builds those enums with their value names as values, which is what graphql-java does for enums without a class. "Expected enum with name" and "is not a Java enum" still apply to every other enum.

The field-use check came out of review. My first version built any classless directive enum from its names, even when a Map-bound input field or the argument of a field with no resolver also used it. That meant adding an unrelated directive could turn a schema that failed to build into one that built and handed Strings to user code. Now any use outside directive definitions needs a class, the same as on master.

Left out:

• Input objects used only by directive arguments still need a class. I kept to the enum case from the issue and away from the input object scanning in Register input field types that have no Java property #842.
• An enum reached through a directive's input object counts as used by that input object's fields, so it still needs a class, as on master.
• There's no dedicated error for an enum used by a directive and by a field the scanner can't find a class through. It falls through to the parser's "Expected enum with name 'Purpose' but found none!". Register input field types that have no Java property #842 gives the Map-bound input case a clearer message.
• extend enum is still ignored, the same as for enums backed by a class.

createDirectives, determineInputType and buildAppliedDirectives aren't touched, so the overlap with #843 is a few nearby lines in SchemaParser. #842 will have a small textual conflict just above validateAndCreateResult, where both add code. Both PRs fail on an enum used by a Map-bound input field, but #842 throws its own SchemaClassScannerError before the parser runs. Whichever lands second has to update the expected exception for the Map case in scanner requires a Java enum for enums used by directives and by fields.

There are 5 new tests in SchemaClassScannerDirectiveTest. The build tests cover the issue's schema exactly as written, applied schema directives using the enum's default and an explicit value (checked through getValue(), a full introspection query and SchemaPrinter), a dictionary class for a directive-only enum, and an enum class found through an unused type with includeUnusedTypes. The last test holds the guards: a String parameter still gives "is not a Java enum", and an Object parameter, an Any? property on an unused type, a Map-bound input field and an unimplemented field's argument in extend type Query still give "Expected enum with name". The existing scanner should handle directives with enum input value already covers an enum used by both a directive and a resolver. I ran the test file against master: the issue schema, applied directives and unused type tests fail with the error above, and the guards test fails at the unused type case, since master throws its scanner error, not the parser's. The dictionary test and the existing tests pass on master. clean verify passes.

Behaviour change: an enum that only directive definitions use, with no dictionary class, now builds instead of failing. Its values are the value names as Strings, so appliedDirective.getArgument("for").getValue<...>() in a SchemaDirectiveWiring returns "SECURITY", not an enum constant. Passing the enum in the dictionary (.dictionary(Purpose::class)) brings the constants back. These enums are now in the built schema and no longer show up in getUnusedDefinitions(). The scanner error "Enum type '...' is used in a directive, but no class could be found for that type name" is gone. Schemas that hit it because the enum is also used by a field without a class still fail, now with the parser's "Expected enum with name 'Purpose' but found none!". Fed2 users who load federation's definitions still have to pass its custom scalars (Import, FieldSet and so on) to the parser.

🤖 Generated with Claude Code