Fragment is never used if you used more than once in the same query

[yurisbel-hernandez]

I'm getting Fragment is never used if I try to reuse a fragment more than once in the same query.

To Reproduce
Configure router and 2 subgraph’s
Hit the router with

query {
    computer(id:"computer-x") {
      specs {
        info
        ...SpecsFragment
        __typename
      }
      __typename
    }
    office(id:"office-x") {
      computers(first:10) {
        location
        specs {
          ...SpecsFragment
          __typename
        }
        __typename
      }
      __typename
    }
}

fragment SpecsFragment on Specs {
  id
  ram
  weight
  __typename
}

Subgraph 1 is getting this query.

query {
    computer(id:"computer-x") {
      specs {
        ...on Specs {
          __typename
          id
          ram
          weight
        }
      }
      __typename
    }
    office(id:"office-x") {
      computers(first:10) {
        location
        specs {
          ...on Specs {
            __typename
            id
            ram
            weight
          }
        }
        __typename
      }
      __typename
    }
}

fragment SpecsFragment on Specs {
  id
  ram
  weight
}

Expected behavior

• Router pass down the query without modifications or if is replacing the fragment for an inline one remove the unused fragment

Output

"code": "GRAPHQL_VALIDATION_FAILED",
      "exception": {
        "stacktrace": [
          "GraphQLError: Fragment \"SpecsFragment\" is never used.",
          "    at Object.leave (/Users/xx1/code/sample/node_modules/graphql/validation/rules/NoUnusedFragmentsRule.js:46:33)",

Desktop

• OS: iOS
• router v0.16

Note
I already tried

traffic_shaping:
  deduplicate_variables: false # Enable the variables deduplication optimization
  all:
    deduplicate_query: false

and getting the same error

[hobbsh]

We hit this on v0.16 and upgraded to the most recent RC (a huge pain without a documented upgrade path) and it worked. Not a great solution at all but it seems like something must've happened on the Apollo Studio side of things that made it incompatible.

[Geal]

this is an issue that has been fixed recently in the query planner #1633 and published in 1.0.0-alpha.1

@hobbsh which issues did you see when upgrading? Are there things we should explain more precisely in the changelog?

[hobbsh]

@Geal I had a hard time understanding the config structure changes because I had to piece things together based on the changelog. I suspect we're not the only case here and it would be good to clearly document upgrade paths (like v0.16.0 to v1.0), mostly related to the configuration changes but also other things like healthcheck path changes, etc.

Also, I think most of the documentation is updated to v1.0 (here) so anyone running previous versions would be trying to implement invalid configurations. Versioned documentation would be a good idea but honestly maybe just a documented full configuration per supported version would be a good first step.

I've seen other projects also use a compatibility matrix but I'm not completely sure how useful that would be here.

[Geal]

@hobbsh the changelog was the right place to look at to understand the upgrade path. We took care in explaining clearly the breaking changes, but maybe that was not enough. Could you point at specific instances that were confusing so we can improve the changelog moving forward?

Please understand that every release before 1.0, which was published yesterday, was a preview without guarantee of stability and upgrade paths, because everything was still in development. Keeping versioned docs and upgrade docs for each of those versions was completely impractical for us. That said, now that 1.0 is published, you can expect the documentation to be stable, and any breaking changes would have to wait for a far off 2.0 version, for which we'll indicate clearly the changes.

[Geal]

@yurisbel-hernandez did updating the router fix the issue for you?

[abernix]

I'm going to close this as I believe it's fixed. Happy to re-open if that turns out not to be the case. Thanks for reporting this originally!