Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#905 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
graphql, java, kotlin
Bereich
backend-api-design, testing

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache
Kotlin
Sterne
824
Forks
175
Ø Merge
2 T. 1 Std.
Gemergte PRs (30 T.)
59

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus graphql-java-kickstart/graphql-java-tools

Alle Issues in graphql-java-kickstart/graphql-java-tools

Ähnliche Issues

Weitere Issues zu Kotlin

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.