Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Directive wirings see a type reference on recursive input fields

Ouverte
#875 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@oryan-block y travaille déjà.

Depuis le 20/10/2026.

  • #895 par @oryan-block — ouverte

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
java, kotlin

Piste de recherche

Start by comparing this schema's directive wiring during type construction with graphql-java's SchemaGenerator behavior described in the issue; the issue names no source files or tests. Reproduce the recursive Tree input case and confirm the GraphQLTypeReference seen for and. Done means directive wiring runs after schema assembly and recursive fields expose the resolved input type across the affected object, interface, union, enum, and input object cases.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug

A SchemaDirectiveWiring that looks at the type of a recursive input field gets a GraphQLTypeReference instead of the input object:

directive @check on INPUT_FIELD_DEFINITION

type Query {
    trees(filter: Tree): Int
}

input Tree {
    and: [Tree!] @check
    name: String @check
}

In onInputObjectField, GraphQLTypeUtil.unwrapAll(element.type) is a GraphQLTypeReference for and (name is a GraphQLScalarType as expected). The same schema and wiring through plain graphql-java's SchemaGenerator gives a GraphQLInputObjectType for and.

So any wiring that walks input types and calls unwrapAll fails with ClassCastException: GraphQLTypeReference cannot be cast to GraphQLUnmodifiedType. I believe that includes graphql-java-extended-validation's DirectivesAndTypeWalker, but I haven't run it against this schema.

#843 fixed the non-recursive case (input objects behind a list or non-null wrapper) and left cycles out. Types are immutable, so one field of a cycle has to stay a reference while the type is being built. graphql-java only runs directive wirings once the whole schema is assembled, so its wirings never see that reference. Ours run while types are being built, so they do.

The fix is probably to hold off all directive wiring until the schema is assembled. That touches objects, interfaces, unions and enums too, not just input objects. I haven't prototyped it.

Not the same as #36 or #450. Those were about recursive inputs not building at all, and that's fixed.

Langage dominant
Kotlin
Étoiles
824
Forks
175
Merge moyen
2 j 5 h
PR mergées (30 j)
52

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de graphql-java-kickstart/graphql-java-tools

Toutes les issues de graphql-java-kickstart/graphql-java-tools

Issues similaires

Plus d'issues Kotlin

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.