You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Failed validation, i.e. additional field not present in schema, leads to duplicate responses, no context enhancements possible, introspection query and empty result..
#6259
Open
1 of 4 tasks
PlayAnyData opened this issue
Nov 9, 2023
· 2 comments
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:
Create a mesh with a query.
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.
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.
The text was updated successfully, but these errors were encountered:
Issue workflow progress
Progress of the issue based on the
Contributor Workflow
Github,
Execution instructions are in the repo in the readme.
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:
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:
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:
"@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"
: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.
The text was updated successfully, but these errors were encountered: