Apollo-client: Apollo Boost Union Query Failure

[Negan1911]

Intended outcome:
I should be able to actually get the data of my query:

{
  "data": {
    "current_user": {
      "__typename": "MarketplaceShopperSchema",
      "email": "[email protected]",
      "activated": true,
      "row_id": 50
    }
  }
}

Actual outcome:
Got an error:

You are using the simple (heuristic) fragment matcher, but your queries contain union or interface types.
     Apollo Client will not be able to able to accurately map fragments.To make this error go away, use the IntrospectionFragmentMatcher as described in the docs: https://www.apollographql.com/docs/react/recipes/fragment-matching.html
WARNING: heuristic fragment matching going on!
Missing field is_active in {
  "__typename": "MarketplaceShopperSchema",
  "email": "[email protected]",
  "act
{ data: null, loading: false, networkStatus: 7, stale: true }

How to reproduce the issue:

1. Create a nodejs script with the following:

require('isomorphic-unfetch')
const gql = require('graphql-tag')
const Client = require('apollo-boost')

const client = new Client.default({
  uri: 'https://aaron.shiphero.com/marketplace' // replace with your url
})

const query = async () => {
  return await client.query({
   // replace with your union type query
    query: gql`
      query GetUser {
        current_user {
          __typename
          ... on MarketplaceShopperSchema {
            email
            activated
            row_id
          }
          ... on User {
            row_id
            is_active
            email
          }
        }
      }
    `
  })
}

query().then(res => {
  console.log(res)
})

1. install dependencies, replace url and query with a similar query
2. run

Disclaimer
I know that for cache purposes i should be using IntrospectionFragmentMatcher but i only want to query the data, i'm able to do that from Graphiql, i don't see why it would not work on the client

Versions

System:
OS: macOS High Sierra 10.13.5
Binaries:
Node: 9.8.0 - /usr/local/bin/node
npm: 6.1.0 - /usr/local/bin/npm
Browsers:
Chrome: 67.0.3396.87
Firefox: 59.0.3
Safari: 11.1.1
npmPackages:
apollo-boost: ^0.1.10 => 0.1.10
apollo-cache-inmemory: ^1.2.5 => 1.2.5
apollo-client: ^2.3.5 => 2.3.5
apollo-link-http: ^1.5.4 => 1.5.4

[Negan1911]

Checked that manually writing the query to apollo-link-http works, maybe having a way to use the client without query? :/

[chinmaybijwe]

I followed this, and it solved my problem when I had union types

https://www.apollographql.com/docs/react/advanced/fragments.html#fragment-matcher

Basically you need to extract all possible types for your fragments when you're dealing with unions and interfaces.
The documentation suggests I should upgrade from apollo boost, but I didn't need to.

[Negan1911]

Yup, but what if i don't want to extract the types? even if i don't care about the cache the request shouldn't fail

[chinmaybijwe]

Agreed with it shouldn't fail. Was it a warning before?
It's really more helpful if you perform type-checking against your schema, which we really make use of.

[Negan1911]

The only warning is that for cache i should be using IntrospectionFragmentMatcher, my use case is really specific and i don't actually care about the cache (runs only one query from a lambda function once), i resolved it by just using apollo-link-http, but idk, there isn't a way to create a client without cache or work directly with union types as-is without getting the error

[trevorlitsey]

I'm using the IntrospectionFragmentMatcher and am receiving the same error

[hwillson]

The You are using the simple (heuristic) fragment matcher ... message is just a warning, and is only displayed once in development. If you don't care about it, please feel free to ignore it. If you don't want to use the cache when querying, use the no-cache fetch policy:

client.query({
  query: [your query],
  fetchPolicy: 'no-cache',
  ...

@trevorlitsey Please consider opening a separate issue, with a reproduction, relating to your comment in https://github.com/apollographql/apollo-client/issues/3605#issuecomment-401416412.

Thanks!