Query planning/validation fails with @include and different field arguments

[carldunham]

Describe the bug

Demonstrated in https://github.com/carldunham/apollo-router-6217.

Given the attached schema, this query

query Broken($full: Boolean = true) {
  posts {
    ...compactView
    ...fullView @include(if: $full)
  }
}

fragment compactView on Compact {
  post {
    media(maxWidth: 216)
  }
}

fragment fullView on Full {
  post {
    media(maxWidth: 640)
  }
}

will fail.

A similar query will provide correct results with the same fragments:

query Works {
  posts {
    ...compactView
    ...fullView
  }
}

Note that the value of the variable doesn't matter, and it doesn't even need to be a variable:

query Broken {
  posts {
    ...compactView
    ...fullView @include(if: false)
  }
}

To Reproduce

Steps to reproduce the behavior:

1. Clone the provided repo
2. Link, download, or copy whatever version of rover and router you want to test with
3. Run make supergraph run
4. Execute the provided query in the sandbox
5. See error
6. (if you want to see results, run the subgraph services like (cd a && make run)

Expected behavior

Working subgraph queries and results.

Output

Router will return

{
  "errors": [
    {
      "message": "Fields \"media\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.",
      "locations": [
        {
          "line": 1,
          "column": 163
        }
      ],
      "extensions": {
        "code": "GRAPHQL_VALIDATION_FAILED"
      }
    }
  ]
}

Desktop (please complete the following information):

• OS: MacOS
• Version 15.0.1

Additional context

Tested with various recent versions, up to

• Rover v0.26.2 with federation =2.9.0
• Router v1.57.0

[goto-bus-stop]

Thank you for the detailed report. I agree this looks like a bug in planning. I've filed a ticket internally to track the work; I would expect it could be fixed in 1.58.0 towards the end of this month

[goto-bus-stop]

(Without the @include, it does not error, but it uses the wrong value for the argument!)

[goto-bus-stop]

Ahh I see what's happening now. This is related to a limitation of the entity mechanism today. There are two different selections for the SimplePost entity in this query. They both end up being used in the same _entities subselection.

We currently have a way to work around this: type conditioned fetching, which splits up the _entities query into multiple requests with the appropriate separate selections. Type conditioned fetching fixes a bug, but it's not enabled by default because it can have prohibitive performance impacts on large queries.

If you run into this in production, you could try enabling type conditioned fetching in the router, and assess if the performance is acceptable for your queries:

experimental_type_conditioned_fetching: true

[carldunham]

Thanks, @goto-bus-stop. That would impact all queries, right? We've got some whoppers!

[goto-bus-stop]

Correct, it would affect all queries. A performance hit would be most noticeable on queries involving very many entities, I think.

[carldunham]

Confirmed