Apollo misses populating properties when fragments are spread

Consider the following query —

  query GetMarketplaceAppListingById {
    marketplaceApp(appId: 1215460) {
      versions(first: 1) {
        edges {
          node {
            deployment {
              compatibleProducts {
                id
                ...Fragment1
              }
            }
          }
        }
      }
    }
  }

  fragment Fragment1 on CompatibleAtlassianProduct {
    __typename
    atlassianProduct {
      name
    }
  }

Here, If I spread Fragment1 instead of inlining properties, Apollo will not make the properties inside Fragment1 (e.g. atlassianProduct) available as data when using useQuery.

However, using the same query with a fetch POST request returns expected results.

Intended outcome: All fields inside the spread fragment should be visible in data

Actual outcome: All fields inside the spread fragment are ignored. However, If I inline properties of the fragment, expected results are obtained.

How to reproduce the issue: See minimal reproduction — https://codesandbox.io/s/apollo-graphql-fragment-bug-50yzl Versions 3.3.x

[benjamn]

@pastelsky The issue here is that Apollo Client does not automatically know that CompatibleAtlassianDataCenterProduct is a subtype of the fragment type condition CompatibleAtlassianProduct. If the type names matched exactly, everything would work, but when subtyping is involved, you need some additional cache configuration.

The way to configure this information is by passing a possibleTypes object to the InMemoryCache constructor:

const client = new ApolloClient({
  cache: new InMemoryCache({
    possibleTypes: {
      CompatibleAtlassianProduct: [
        // List of all known direct subtypes of CompatibleAtlassianProduct:
        "CompatibleAtlassianDataCenterProduct",
        // ...
      ],
    },
  }),
  uri: "https://api.atlassian.com/graphql"
});

While you can mostly get away with manually listing only the subtypes that you actually need, you might want to generate possibleTypes automatically from your schema. Here are some instructions for how you might set that up.

[pastelsky]

Thanks @benjamn . I’ll try this solution out. But regardless, I think it would be helpful to inform the user that a field type might not be resolvable using the currently available information and possibleTypes should be provided.

I found skipping of fields to be quite non-intuitive.