query returns object from cache with no fields except __typename even when selected

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 

[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