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
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:
queryMyQuery2 {
BaseObject(filter: {id: {eq: "09445c10-6b73-11ed-b68a-8f3ad0a07170"}}) {
id
}
}
without additionalResolvers & additionalTypeDefs the serialized POST request body seems straight forward & correct:
Issue workflow progress
Progress of the issue based on the Contributor Workflow
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
query:
additionalResolvers
&additionalTypeDefs
the serialized POST request body seems straight forward & correct:additionalResolvers
&additionalTypeDefs
the serialized POST request body is differentExpected behavior
I would expect the results to look the same
Environment:
The text was updated successfully, but these errors were encountered: