Open
Description
Issue workflow progress
Progress of the issue based on the Contributor Workflow
- 1. The issue provides a reproduction available on Github, Stackblitz or CodeSandbox
Make sure to fork this template and run
yarn generate
in the terminal.Please make sure Mesh package versions under
package.json
matches yours.
- 2. A failing test has been provided
- 3. A local solution has been provided
- 4. A pull request is pending review
Describe the bug
Nested graphql input get serialized differently when (empty) additionalResolvers
& additionalTypeDefs
are specified.
Apparently input gets extracted and added to the variables section. While this might be spec compliant it looks strange that this behavior is triggered just by the existance of eg additionalTypeDefs
and creates issues eg. when used with EdgeDB.
To Reproduce
- run a query that leads to a graphql service behind mesh with nested input, such as
query:
query MyQuery2 {
BaseObject(filter: {id: {eq: "09445c10-6b73-11ed-b68a-8f3ad0a07170"}}) {
id
}
}
- without
additionalResolvers
&additionalTypeDefs
the serialized POST request body seems straight forward & correct:
'{"query":"query MyQuery2 {\\n BaseObject(filter: {id: {eq: \\"09445c10-6b73-11ed-b68a-8f3ad0a07170\\"}}) {\\n id\\n }\\n}","operationName":"MyQuery2","extensions":{"headers":{},"endpoint":"http://localhost:10703/db/edgedb/graphql"}}'
- with
additionalResolvers
&additionalTypeDefs
the serialized POST request body is different
'{"query":"query MyQuery2($_v0_filter: FilterBaseObject) {\\n __typename\\n BaseObject(filter: $_v0_filter) {\\n id\\n __typename\\n }\\n}","variables":{"_v0_filter":{"id":{"eq":"09445c10-6b73-11ed-b68a-8f3ad0a07170"}}},"operationName":"MyQuery2","extensions":{"headers":{},"endpoint":"http://localhost:10703/db/edgedb/graphql"}}'
Expected behavior
I would expect the results to look the same
Environment:
- OS: MacOS 13
- "@graphql-mesh/cli": "^0.79.6",
- "@graphql-mesh/graphql": "^0.32.0",
- NodeJS: 18
Metadata
Metadata
Assignees
Labels
No labels