Apollo-client: Query containing only fragments does not work

[rlotufo]

Intended outcome:
Trying to query using fragments, using a query like:

const frag = gql`
  fragment peopleFrag on Query {
    people {
      id
      name
    }
  }
`;

const query = gql`
 query ErrorTemplate {
   ...peopleFrag
 }
${frag}
`

Actual outcome:
The query never gets sent to the graphql server

How to reproduce the issue:
I reproduced this using the react-apollo-error-template. Just replace the query in App.js with:

const frag = gql`
  fragment peopleFrag on Query {
    people {
      id
      name
    }
  }
`;

export default graphql(
  gql`
    query ErrorTemplate {
      # people {
      #   id
      # }
      ...peopleFrag
    }
    ${frag}
  `
)(App);

If you uncomment the three lines above, the query will work.

Version

• apollo-client: 2.0.1

[Lorti]

Declare your frag without the gql tag.

[rlotufo]

That did not work. I'm now using this and it does not work:

export default graphql(
  gql`
    query ErrorTemplate {
      ...peopleFrag
    }
    fragment peopleFrag on Query {
      people {
        id
        name
      }
    }
  `
)(App);

[abhiaiyer91]

According to the GraphQL spec:

Fragments must specify the type they apply to.
Fragments can be specified on object types, interfaces, and unions.

So the correct way to write your fragment above is like this:

  query ErrorTemplate {
      people {
        ...peopleFrag
      }
    }
    fragment peopleFrag on Person {
      people {
        id
        name
      }
    }

where the peopleFrag is a fragment of the type Person.

[rlotufo]

My peopleFrag is a fragment on Query, which, from my understanding, is a type. So it seems I am adhering to the GraphQL spec. Or am I mistaken?

[abhiaiyer91]

I think you're definitely right, Query is an object type! I tried doing some research on other code and havent ever seen a fragment on Query!

[stubailo]

Wow! This looks like it might be quite an oversight, but it should definitely work!

[abhiaiyer91]

Assigning this to myself.

So i indeed reproduce this error in the error template project. I do not reproduce this in apollo dev tools querying from graphiql.

I also tried to write a failing test for this in AC, but nothing fails. So I'm going to look at react apollo next and report back.

[rlotufo]

Awesome! Thanks for looking into it :)

[abhiaiyer91]

Here is a PR in React apollo that demonstrates the failure

https://github.com/apollographql/react-apollo/pull/1987

One test is to verify that my understanding of fragment on X (non query object types) works.
Second, the failing one, shows fragment on Query fails

[stubailo]

@abhiaiyer91 weird, so it's a react-apollo issue somehow?

[abhiaiyer91]

@stubailo Looks like it, im gonna work on this tomorrow and figure out why its broken

[abhiaiyer91]

This is actually an apollo-client bug. And ill have some code to address this soon.

[abhiaiyer91]

The reason this happens is when AC attempts to make a query that has a selection set with a fragment on Query it will return this data: { [Symbol(id)]: 'ROOT_QUERY' }. So if you're using cache based fetch policies, AC thinks it has data for this query in cache and returns it to you. Since network-only doesn't read from cache, this bug doesn't happen

What we want to have happen here is when we do the diff when fetching queries we need to mark the context as missing fields: https://github.com/apollographql/apollo-client/blob/master/packages/apollo-cache-inmemory/src/readFromStore.ts#L125 which right now it is coming back as false.

Going deeper there, the reason we arent executing this right now is because our selection set only has a fragment, and if youre using the Heuristic fragment matcher it doesnt attempt to resolve sub fields in the fragment when the only root id is ROOT_QUERY

This fixes the issue https://github.com/apollographql/apollo-client/pull/3484

[BrentLayne]

Currently seeing this issue. Are there any plans to fix this?

[vnenkpet]

I also have this same issue. Using apollo-boost 0.1.15. This should definitely work right?

[JakeDawkins]

@BrentLayne this CodeSandbox shows the same issue. If you update the cache package to latest it shows the fix. This _should_ be resolved in the latest apollo-cache-inmemory.

[zyqxd]

It seems like this issue is still present (apollo-cache-inmemory@^1.2.10) when apollo client is using IntrospectionFragmentMatcher

The fix added a check here for HeuristicFragmentMatcher.match, but neglected to do so for IntrospectionFragmentMatcher.match here.

@abhiaiyer91 would your fix also work for IntrospectionFragmentMatcher?

[MargaretKrutikova]

I am testing out apollo-client 3.0.0-beta and it doesn't seem to call a query that only contains a fragment, seems like a regression?

[Gaia-Nutrition]

Experiencing the same on 3.0.0-beta.24 but tried downgrading all the way to 3.0.0-beta.12. Same issue. A query that contains only a fragment is not being called.
My current workaround is to add a random field to the queries in question that is also part of the fragment.

[MargaretKrutikova]

Is there any plan to fix this? It seems to me like a pretty serious issue resulting in unexpected bugs that are extremely difficult to trace. Appreciate any help here! :)

[northout-muzammil]

Anyone please provide fix for this issue I am also facing the same.

[mikeaustin]

My issue is that it doesn't see a second fragment that I created, saying the fragment doesn't exist.
I just moved the fragment definition to an inline non gql string:

const GET_TASK_DETAILS = gql`
  query TaskDetails($taskId: String) {
    story(taskId: $taskId) {
      ${fragments.taskDetails}
    }
  }
`;

Maybe it's a little less performant, but it works.