GraphQL RFC Tracker

RFC X / Rejected

Remove fragmentSpreadName from visitedFragments when visit is complete

Opened on2023-09-11
Closed on2025-07-17

At a glance

Spec PR description

@robrichard raised an issue for @defer whereby under the current draft specification if you have this query:

query HeroNameQuery {
  hero {
    ...NameFragment
    ...NameFragment @defer
  }
}
fragment NameFragment on Hero {
  name
}

then the @defer will never be visited; but if you move the @defer earlier:

query HeroNameQuery {
  hero {
    ...NameFragment @defer
    ...NameFragment
  }
}
fragment NameFragment on Hero {
  name
}

then the non-deferred version will never be visited.

@mjmahone has an RFC open about fragment arguments which suffers a similar issue: visits to a fragment aren't equivalent depending on the variables.

query HeroNameQuery {
  hero {
    ...ComponentOne
    ...ComponentTwo
  }
}
fragment ComponentOne on Hero {
  id
  ...HeroDetails(includeBio: true, includeAvatar: false)
}
fragment ComponentTwo on Hero {
  ...HeroDetails(includeBio: false, includeAvatar: true)
}
fragment HeroDetails($includeBio: Boolean!, $includeAvatar: Boolean!) on Hero {
  superheroName
  realName
  initials
  ... @include(if: $includeAvatar) {
    avatarLarge 
    avatarSmall
  }
  ... @include(if: $includeBio) {
    bioTitle
    bioSubtitle
    bioEntryParagraph
    bioQuote
    bioMainText
  }
}

Matt's solution takes a Relay-esque approach and generates a key for the fragments based on the values of their arguments.

Another consideration is where there are user-defined directives; e.g. { id ...Profile name ...Profile @live } might benefit from walking Profile again now that it has @live attached.

A simple solution to this is rather than each of these problems having their own solution, to simply navigate the fragment spread again - it's only a single layer that we need to worry about, so the cost is likely to be marginal. This RFC proposes this with a tiny change to the spec - after adding the fragmentSpreadName to visitedFragments, and calling CollectFields, we then remove it again.

Timeline