Apollo-client: query returns object from cache with no fields except __typename even when selected

[capaj]

EDIT: the description is from before @dmoree identified the problem.

As a workaround I am able to see all the fields in my data when I call the hook with fetchPolicy: 'no-cache'

With all the other policies, the bug occurs.
This is my query:

fragment TopicDetailsForResourceCard on ITopicModel {
  id
  currentTitle
  is_archived
  created_at
  currentTopicVersion {
    id
    title
    duration
    summary
  }
  author {
    id
    email
    image_url
    username
    profile_img_url
  }

  lastEnrolment {
    id
    completion_date
    progress
    target_completion_date
  }

  coverImage {
    id
    cdnUrl
    imageVariants {
      cdnUrl
    }
  }
}

query workspaceTopicsAndThemes($workspaceId: PositiveInt!) {
  workspace(id: $workspaceId) {
    id
    description
    name
    coverImage {
      id
      cdnUrl
      imageVariants {
        cdnUrl
      }
    }
    topics(filters: [{ name: noTheme }, { name: withCurrentVersion }]) {
      ...TopicDetailsForResourceCard
    }
    themes {
      id
      title
      topics(filters: [{ name: withCurrentVersion }]) {
        ...TopicDetailsForResourceCard
      }
    }
  }
}

Intended outcome:
query result is the same for every cache policy
This is how I would like them to look:

Actual outcome:
query returns items that only have __typename attribute.
This is how the data for topics look:

How to reproduce the issue:
sorry, it only happens in our codebase, I wasn't able to repro on codesandbox yet.

Versions

  System:
    OS: Linux 5.4 Ubuntu 20.04 LTS (Focal Fossa)
  Binaries:
    Node: 12.14.1 - ~/.nvm/versions/node/v12.14.1/bin/node
    Yarn: 1.22.4 - ~/.yarn/bin/yarn
    npm: 6.13.4 - ~/.nvm/versions/node/v12.14.1/bin/npm
  Browsers:
    Chrome: 84.0.4147.89
    Firefox: 78.0.2
  npmPackages:
    @apollo/client: ^3.0.2 => 3.0.2 
    @apollo/link-batch-http: ^2.0.0-beta.3 => 2.0.0-beta.3 
    @apollo/link-context: ^2.0.0-beta.3 => 2.0.0-beta.3 
    @apollo/link-error: ^2.0.0-beta.3 => 2.0.0-beta.3 
    @apollo/link-schema: ^2.0.0-beta.3 => 2.0.0-beta.3 
    @apollo/react-components: ^3.1.5 => 3.1.5 
    @apollo/react-ssr: ^3.1.5 => 3.1.5 
    @apollo/react-testing: ^3.1.4 => 3.1.4 
    apollo-cache-inmemory: ^1.6.6 => 1.6.6 
    apollo-client: ^2.6.10 => 2.6.10 
    apollo-server: ^2.15.1 => 2.15.1 
    apollo-server-express: ^2.15.1 => 2.15.1 
    react-apollo: ^3.1.5 => 3.1.5 

[benjamn]

This is just a guess, but I'm feeling some déjà vu from https://github.com/apollographql/apollo-client/issues/6599#issuecomment-658811625: does anything change if you explicitly add a __typename field to the TopicDetailsForResourceCard fragment?

[capaj]

no, doesn't have any effect on the issue.
I have tried adding it to the root of the fragment and for each object type as well.

[dmoree]

Does TopicModelAsEditor implement an interface? And if so, is it listed in the possibleTypes of the interface? Or are there any types that implement an interface that are not listed in possibleTypes? I had an issue earlier where I forgot to include the type into the possible types of the interface and experienced something similar, although in my case it was returning only __typename and id fields. My apologies if this is obvious and/or unhelpful.

[capaj]

@dmoree it does implement an interface and I don't think I am listing possibleTypes. Is this documented anywhere?

EDIT: oh I am getting the possibleTypes generated from @graphql-codegen and I am using those when I create apollo-client in the fragmentMatcher field.
I tried commenting out the fragmentMatcher and that did not change the outcome.

I just retested with "@apollo/client": "^3.1.2",, still getting those empty objects. Bug still reproducable.

[dmoree]

@capaj For @apollo/client I believe they are moving away from fragmentMatcher and towards explicitly declaring possible types through the possibleTypes field in InMemoryCache. Here is the documentation regarding possible types of interfaces and unions:
https://www.apollographql.com/docs/react/data/fragments/#using-fragments-with-unions-and-interfaces

I am also using @graphql-codegen. Here is the documentation regarding the use in apolloClientVersion: 3 (i.e. @apollo/client):
https://graphql-code-generator.com/docs/plugins/fragment-matcher#usage-with-apollo-client-3

Removing the fragmentMatcher field and explicitly adding the possibleTypes field using the example in @graphql-codegen documentation may be the solution to your problem.

[napikwaan]

I was having this exact problem and adding the possibleTypes field to my InMemoryCache configuration did indeed remedy the issue.

*edited: grammar

[capaj]

@dmoree thank you very much. I just tested adding the possibleTypes and it totally works now!

I will rename this ticket. I think it would be worth adding a warning/error when this happens because it is a very easy to make this configuration issue and I bet dozens of people will be landing here from google.

[capaj]

actually, just to keep it tidy I'll close this ticket and create a new one for the warning/error throwing.