Description

alf

opened on Mar 30, 2026

Issue body actions

From what I can see there is currently no good way to see whether or not a field is part of a fragment with the @defer directive. As a result, I’m not able to postpone fetching deferred fields in my datafetchers.

Am I missing something, or is this something we can and should improve?

Activity

1. bbakerman commented on Mar 30, 2026

   

   bbakerman

   on Mar 30, 2026

   Member

   More actions

   I’m not able to postpone fetching deferred fields in my datafetchers.
   Am I missing something,

   The DataFetcher is not responsible for "deferring" fields - that is on the engine itself.

   So given

   query PersonQuery($personId: ID!) {
     person(id: $personId) {
       # Basic fields (fast)
       id
       firstName
       lastName
       # Friend fields (slower)
       ... @defer {
         friends {
           id
         }
       }
     }
   }
   

   The engine will look for @defer directives on fragments and then find all the fields that are inside them AND then skip executing the fields until it has done all the non deferred fields.

   So in the example above the friends field (and child fields of course) are initially skipped by the engine and then later run aka deferred until later

   Defer is still a experimental (off by default) feature. You need to turn it on per request

           return graphQL.execute(
                   ExecutionInput.newExecutionInput()
                           .graphQLContext([(ExperimentalApi.ENABLE_INCREMENTAL_SUPPORT): incrementalSupport])
                           .query(query)
                           .variables(variables)
                           .dataLoaderRegistry(dataLoaderRegistry)
                           .build())
   
2. alf commented on Mar 31, 2026

   

   alf

   on Mar 31, 2026

   Author

   More actions

   So in your example the selectionset passed by the engine to the query.person datafetcher won’t contain friends? If so, that’s perfect and exactly what I need.

   Reacted by Brad Baker
3. alf

   closed this as completedon Mar 31, 2026
4. alf

   reopened this on Apr 6, 2026
5. alf commented on Apr 6, 2026

   

   alf

   on Apr 6, 2026

   Author

   More actions

   Looked at this again. Unfortunately it seems that the initial datafetcher does include deferred fields in the selectionset. This causes my graphql framework to fetch the data as part of the initial fetch.

   So I’m back with the question: Is there some way for my datafetcher to find out that some fields in the selectionset are deferred?

   See https://github.com/sikt-no/graphitron/blob/0c51b43324b5879ead1763a91e426ed5b6a873c6/graphitron-codegen-parent/graphitron-java-codegen/src/test/java/no/sikt/graphitron/record/DeferBehaviorTest.java where I’ve had Claude make some exploratory tests to see how graphql-java currently acts.
6. bbakerman commented on Apr 7, 2026

   

   bbakerman

   on Apr 7, 2026

   Member

   More actions

   ok good catch - it sounds like graphql.schema.DataFetchingFieldSelectionSet is not respecting deferred fields. The engine is - it will only invoke data fetchers of fields that are not deferred on the initial pass but I can see how graphql.schema.DataFetchingFieldSelectionSet could lead a DF to get data for child fields that it will not need immediately (and hence not defer them).

   I think this needs to be reflected some how in the graphql.schema.DataFetchingFieldSelectionSet model. Not sure off hand how to model it (have a dfSelectionSet.getDeferredFields() ??? say) or make them disappear all together.

   Hmmm we need to ponder on this a bit on how best to model it.
7. github-actions commented on Jun 7, 2026

   

   github-actionsBot

   on Jun 7, 2026 – with GitHub Actions

   Contributor

   More actions

   Hello, this issue has been inactive for 60 days, so we're marking it as stale. If you would like to continue this discussion, please comment within the next 30 days or we'll close the issue.
8. github-actions

   added

   Stale

   on Jun 7, 2026
9. bbakerman

   added

   keep-openTells Stale Bot to keep PRs and issues openTells Stale Bot to keep PRs and issues open

   and removed

   Stale

   on Jun 14, 2026

Issue actions