Repository navigation
Remove missingResolverDataFetcher and the legacy context fallbacks - #915
Merged
oryan-block merged 5 commits intoOct 24, 2026
Merged
Conversation
|
oryan-block
deleted the
feature/846-remove-missing-resolver-data-fetcher
branch
October 24, 2026 00:26
This was referenced Oct 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.




Fixes #846
Checklist
Description
The three breaking cleanups the issue lists for 15.0.0, one commit each, plus a fix commit for the context class.
missingResolverDataFetcheris gone fromSchemaParserOptionsand its builder, with the fallback to it inMissingFieldResolver, the null check inFieldResolverScanner.missingFieldResolverand the test for it. An app that calls it stops compiling, so nothing changes quietly.missingResolverDataFetcherProviderstays.A custom context class (
contextClass) is only read from theGraphQLContextnow. #566 made it look there first and fall back toenvironment.getContext()(whatExecutionInput.context(...)was given), with a warning that said "This warning will become an error in the future". Without the fallback the parameter would have gottennullfor a Java method or a nullable Kotlin parameter, which hides the mistake. So the field fails instead, with an error that names the resolver method and the context class and says to put it in theGraphQLContextunder its class when building theExecutionInput. On master the same mistake already failed withargument type mismatch, unless the app also passed the class as the context object.contextClass(GraphQLContext::class)keeps working: that parameter gets theGraphQLContext, as it did on master through the fallback.A
CoroutineScopeis only read from theGraphQLContextunder theCoroutineScopeclass key now. #350 added the context object route (the app's context implementsCoroutineScope, so each request gets its own scope) and 14.2.0 deprecated it with a warning. Without it, suspend resolvers run inCoroutineScope(Dispatchers.Default)and nothing is logged or fails. That's the one that can go unnoticed: cancelling the app's scope no longer cancels its running resolvers, and the scope's job and context elements aren't there. I didn't add anything to catch it, so the release note has to.Tests:
data fetcher fails if custom context is missing from GraphQLContext,data fetcher fails if custom context is only passed as the legacy context objectanddata fetcher passes GraphQLContext if it is the custom context classare new, and the legacyCoroutineScopetest now asserts the scope isn't used. The fallback tests fail on the unchanged code.mvn clean verifypasses on graphql-java 26.1 and 25.1 (412 tests each).Also checked through the installed jar in a separate consumer project, with a context that is both the
contextClassand aCoroutineScope, passed as the context object. On masternullableContextandstrictContextboth givecontext user: oryan,scopeJobgivesran in the request scope, and the log has the two context warnings and the scope one. On this branch (graphql-java 26.1 and 25.1)nullableContextandstrictContextfail with the new error,scopeJobgivesran in the default scope, and the log is empty. Thecontext-and-environmentscenario, which passes the class through theGraphQLContext, still runs without errors.Release note: three removals for 15.0.0.
SchemaParserOptions.Builder.missingResolverDataFetcher(...)is removed. Replace.missingResolverDataFetcher(fetcher)with.missingResolverDataFetcherProvider { _, _ -> fetcher }.ExecutionInput.context(...)) is no longer given to resolvers. A resolver with a parameter of that class fails the field with an error saying so. Put it in theGraphQLContextunder its class instead, e.g.ExecutionInput.newExecutionInput().graphQLContext(mapOf(MyContext::class.java to myContext)).CoroutineScopethat is only passed as the context object is no longer used by suspend resolvers, and nothing is logged or fails. They run inCoroutineScope(Dispatchers.Default), so cancelling your scope no longer cancels them. Put it in theGraphQLContextunder theCoroutineScopeclass key instead, e.g.graphQLContext(mapOf(CoroutineScope::class.java to scope)).