Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

unwrap nested return values exactly the way the schema build matched them in 15.0.0

Fechada
  • Algo errado?
#905 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Um pull request relacionado já foi integrado.

  • #918 de @oryan-block — integrado

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
graphql, java, kotlin
Domínio
backend-api-design, testing

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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).

Linguagem predominante
Kotlin
Estrelas
824
Forks
175
Merge médio
1d 10h
PRs com merge (30d)
86

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Issues semelhantes

Mais issues de Kotlin

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.