Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

v15: unwrap nested return values exactly the way the schema build matched them

Abierto
  • ¿Algo no está bien?
#905 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
graphql, java, kotlin
Área
backend-api-design, testing

Línea de trabajo

Start with TypeClassMatcher, ReturnValueUnwrapper, and NestedGenericWrapperTest; trace how the matcher records wrappers and how the data fetcher unwraps values. Add the custom scalar and nested Future cases described here, then confirm the matcher’s accepted return types still resolve and the nested Future produces the top-level error. The issue also calls for a release note for each behavior change.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

#903 made generic wrappers and futures nested in lists and other wrappers work at runtime, but it had to keep everything that works on 14.x working. That left a few spots where the schema build and the runtime still don't agree. Fixing them changes behaviour for some apps, so they should go in 15.0.0.

  1. Share the walk. ReturnValueUnwrapper repeats the order TypeClassMatcher.match unwraps in (generic wrappers, DataFetcherResult, Optional, non-null, list elements) instead of sharing it. Right now only NestedGenericWrapperTest keeps the two in step (every return type up to 4 deep that the matcher accepts has to resolve). Instead the matcher should record what it unwrapped, and the data fetcher should replay that. That also fixes a wrapper that only a custom schemaWrapper introduces, which today gets no nested unwrapping.

  2. Custom scalars. They're exempt, so a Coercing keeps getting what it gets today. Which means [DateTime] from List<CompletableFuture<OffsetDateTime>> passes the schema build and then hands the futures to the scalar. Breaking for a Coercing that unwraps them itself.

  3. Nested futures graphql-java can't wait on. List<Future<Item>> (not a CompletionStage) passes through as is and fails with

    Expected source object to be an instance of 'Item' but instead got 'java.util.concurrent.FutureTask'

    unless the app's ValueUnboxer calls get(). It should fail with the same error the top level already gives. Breaking for those unboxers, and the fix on their side is to return a CompletableFuture.

  4. Picking a nested wrapper. We pick it by instance, the same as the outermost one. Picking by declared type would follow what the matcher resolved more closely. I'm not sure it's worth the change, since it only matters when the instance is a subclass registered as a different wrapper 🤔

  5. The resolver's own future. A future directly inside a non-future wrapper (Try<CompletableFuture<X>>) gets no step, only so graphql-java gets the exact future the resolver returned. Dropping that rule (isFutureReturnedByWrapperBefore) would hand it an equal future derived from it instead. Only breaking for someone who compares the instance.

Each one needs a line in the release notes.

resolves every return type the matcher accepts in NestedGenericWrapperTest should stay after this, since it checks the behaviour and not the copy. It should get a custom scalar leaf (2) and Future as a container with the error expected (3).

Lenguaje dominante
Kotlin
Estrellas
824
Forks
175
Merge medio
2 d 1 h
PR fusionados (30 d)
59

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de graphql-java-kickstart/graphql-java-tools

Todos los issues de graphql-java-kickstart/graphql-java-tools

Issues similares

Más issues de Kotlin

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.