Mixing introspection and non-introspection in a query ignores the introspection

[glasser]

Describe the bug There is no such thing as an "introspection query" in GraphQL; the introspection fields such as Query.__schema and Query.__type are just fields that can be in any operation. One theoretically can combine introspection and non-introspection root fields in the same operation. Router appears to not support these operations.

I don't think that these are particularly useful, so this is more of a "lack of perfect fidelity to the spec" than a major missing use case.

To Reproduce Steps to reproduce the behavior:

• Check out router repo (say, f6c70e77)
• Run router in dev mode (to enable introspection): cargo run -- -s examples/graphql/supergraph.graphql --dev
• In another shell:

  $ curl -s http://127.0.0.1:4000/ --json '{"query": "{ __schema { queryType { name } } }"}'; echo
  {"data":{"__schema":{"queryType":{"name":"Query"}}}}
  $ curl -s http://127.0.0.1:4000/ --json '{"query": "{ __schema { queryType { name } } me { id } }"}'; echo
  {"data":{"__schema":null,"me":{"id":"1"}}}

Expected behavior The introspection field __schema that is non-null in the first operation should be non-null in the second operation.

[Collin3]

Ran into this as well! We were using introspection to grab all possible enum values for a form field select dropdown. As a workaround, we exposed a top level Query entry point to fetch the enum values, but I think it would be more desirable to use introspection for fetching that data as opposed to having to maintain a query resolver over time.

[abernix]

Just to acknowledge, this is indeed a known limitation right now due to underlying constraints of how we do query-planning right now, but we've deemed it as acceptable in the near term since it affects so few cases in practice. We will resolve this in the future, but it's probably more than 6 months out as of this writing.

[joemccall86]

As another data point this affects us too.

[JoeTravisKiva]

We are impacted by this as well