Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Chiusa
  • Qualcosa non va?
#905 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #918 di @oryan-block — integrata

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
graphql, java, kotlin
Ambito
backend-api-design, testing

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
Kotlin
Stelle
824
Fork
175
Merge medio
1g 10h
PR unite (30g)
86

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Issue simili

Altre issue su Kotlin

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.