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
This "extensions" section can be used to provide auxilliary information such as profiling information or hints back to callers for performance optimization, or indeed anything else.
This information is lost when stitching in the remote graphql schema into a stitched global schema.
I would expect to be able to provide a merge function for the optional 'extensions' part of the response payload, with a default implementation which would naively merge the map contents.
The text was updated successfully, but these errors were encountered:
Issue workflow progress
Progress of the issue based on the Contributor Workflow
Describe the bug
Stitching a remote schema loses any "extensions" information in the query response of a sub-schema
A GraphQL query response may have a top-level "extensions" field next to the "errors" and "data" fields:
https://spec.graphql.org/June2018/#sec-Response-Format
This "extensions" section can be used to provide auxilliary information such as profiling information or hints back to callers for performance optimization, or indeed anything else.
This information is lost when stitching in the remote graphql schema into a stitched global schema.
I would expect to be able to provide a merge function for the optional 'extensions' part of the response payload, with a default implementation which would naively merge the map contents.
The text was updated successfully, but these errors were encountered: