graphql-tools: Fix error, tracing, and cache control propagation in schema stitching
Right now, errors, tracing info, and other stuff doesn’t always make it across the stitching boundaries. This means sometimes using schema stitching can cause a degradation of developer experience compared to a non-stitched schema.
We should fix that, so that we can recommend stitching without reservation as a first-class way of developing schemas. I’m going to close issues related to this and point them here as a master list.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 22
- Comments: 19
Hate to be this guy… But are there any plans for this feature?
Is this the reason we might not see
info.cachControlin resolvers we build and schema stitch together using graphql-tools? If so this is a pretty big let down because we use schema stitching in our hapi GraphQL server to organize our larger schema and to stitch in remote schemas.checkResultAndHandleErrors is really messing up schema stitching for us
We delegate and get a perfectly nice graphql error back from a downstream service
A transformer that we can’t disable calls checkResultAndHandleErrors, transforms our nice downstream graphql error into an unusable error by concatenating the body into a string?
If we want to pass on (throw) the original downstream error we have no way.