Failed validation, i.e. additional field not present in schema, leads to duplicate responses, no context enhancements possible, introspection query and empty result..

[PlayAnyData]

Issue workflow progress

Progress of the issue based on the Contributor Workflow

• [x] 1. The issue provides a reproduction available on Github,

Execution instructions are in the repo in the readme.

• [ ] 2. A failing test has been provided
• [ ] 3. A local solution has been provided
• [ ] 4. A pull request is pending review

---

Describe the bug

We have created a mesh of different subgraphs. Now, if somebody sends a request with a non-existing field, i.e. query myQuery{ myQuery { items { id toast } } } where toast does not exist in the schema, we face the following issues: The query runs through the following plugin steps:

parse validate (here we can see validation failed) parse (now we have an introspection query for schema) validate execute (here we can see the result of the introspection query)

We are wondering why it is running through the second parse - validate cycle. From debugging we know in this case it sends an introspection query. Even if we tried disabling introspection, e.g. via envelop plugin, it still runs through this second phase.

Additionally, in executeDone we can only see the results of the introspection query, but not the original query's results.

The displayed result, then shows something like this: { "errors": [ { "message": "Field \"toast\" is not defined by type \"myQuery_type\"." }, { "message": "Field \"toast\" is not defined by type \"myQuery_type\"." } ] }

So the result is duplicated.

To Reproduce Steps to reproduce the behavior:

1. Create a mesh with a query.
2. Execute a query with a non-existing field.

Expected behavior

We would have expected to see the validation result in execute phase, or even a context attribute, which we set in the validate phase, with which we would be able to skip execution. However, we can only see the introspection query here.

Environment:

• OS: Windows 11
• "@graphql-mesh/cli": "0.87.14", "@graphql-mesh/graphql": "0.95.7", "@graphql-mesh/http": "0.96.12", "@graphql-mesh/transform-filter-schema": "0.95.7", "@graphql-mesh/transform-rename": "0.95.8":
• NodeJS: v18.18.0

Additional context What we are trying to achieve is creating prometheus metrics with result status codes from all calls filtered by operationName, client, etc. therefore, we would also like to know who is potentially writing bad requests e.g. after a version upgrade.

[ardatan]

Thanks for creating the issue, but we need a reproduction as you can see in the issue template.

[PlayAnyData]

Added repo for reproduction.