graphql-tools: Schema stitching swallows original error stack traces from the children
This is related to the issue here: https://github.com/apollographql/graphql-tools/issues/480 and the (now accepted and closed) PR here: https://github.com/apollographql/graphql-tools/pull/637
The above PR unfortunately only fixes the case when there is an error thrown from a PARENT object in the response. so for example, if the query is something like:
query {
student(id: 5) {
studentId
}
}
HOWEVER, if there is an error thrown within a child field/object’s resolver then graphql’s schema stitching still swallows the error. example:
query {
student(id: 5) {
studentId,
favouriteColor //if sub-resolver throws error here, stack trace will be swallowed
}
}
- has-reproduction
- feature
- docs
- blocking
- good first issue
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 21
- Comments: 27 (6 by maintainers)
Commits related to this issue
- feat(errors): Pass through all possible errors. Use new relocatedError function to update the original GraphQLErrors with the new path. Addresses #743, #1037, #1046, apollographql/apollo-server#1582. — committed to yaacovCR/graphql-tools-fork by hwillson 5 years ago
- feat(errors): Pass through all possible errors. Use new relocatedError function to update the original GraphQLErrors with the new path. Addresses #743, #1037, #1046, apollographql/apollo-server#1582. — committed to yaacovCR/graphql-tools-fork by hwillson 5 years ago
- feat(errors): Pass through all possible errors. Use new relocatedError function to update the original GraphQLErrors with the new path. Addresses #743, #1037, #1046, apollographql/apollo-server#1582. — committed to yaacovCR/graphql-tools-fork by hwillson 5 years ago
- feat(errors): Pass through all possible errors. Use new relocatedError function to update the original GraphQLErrors with the new path. Addresses #743, #1037, #1046, apollographql/apollo-server#1582. — committed to yaacovCR/graphql-tools-fork by hwillson 5 years ago
- feat(errors): Pass through all possible errors. Use new relocatedError function to update the original GraphQLErrors with the new path. Addresses #743, #1037, #1046, apollographql/apollo-server#1582. — committed to yaacovCR/graphql-tools-fork by hwillson 5 years ago
- feat(errors): Pass through all possible errors. Use new relocatedError function to update the original GraphQLErrors with the new path. Addresses #743, #1037, #1046, apollographql/apollo-server#1582. — committed to yaacovCR/graphql-tools-fork by hwillson 5 years ago
- feat(errors): Pass through all possible errors. Use new relocatedError function to update the original GraphQLErrors with the new path. Addresses #743, #1037, #1046, apollographql/apollo-server#1582. — committed to yaacovCR/graphql-tools-fork by hwillson 5 years ago
- feat(errors): Pass through all possible errors. Use new relocatedError function to update the original GraphQLErrors with the new path. Addresses #743, #1037, #1046, apollographql/apollo-server#1582. — committed to yaacovCR/graphql-tools-fork by hwillson 5 years ago
- feat(errors): Pass through all possible errors. Use new relocatedError function to update the original GraphQLErrors with the new path. Addresses #743, #1037, #1046, apollographql/apollo-server#1582. — committed to yaacovCR/graphql-tools-fork by hwillson 5 years ago
- feat(errors): Pass through all possible errors. Use new relocatedError function to update the original GraphQLErrors with the new path. Addresses #743, #1037, #1046, apollographql/apollo-server#1582. — committed to yaacovCR/graphql-tools-fork by hwillson 5 years ago
- feat(errors): Pass through all possible errors. Use new relocatedError function to update the original GraphQLErrors with the new path. Addresses #743, #1037, #1046, apollographql/apollo-server#1582. — committed to yaacovCR/graphql-tools-fork by hwillson 5 years ago
- feat(errors): Pass through all possible errors. Use new relocatedError function to update the original GraphQLErrors with the new path. Addresses #743, #1037, #1046, apollographql/apollo-server#1582. — committed to yaacovCR/graphql-tools-fork by hwillson 5 years ago
- feat(errors): Pass through all possible errors. Use new relocatedError function to update the original GraphQLErrors with the new path. Addresses #743, #1037, #1046, apollographql/apollo-server#1582. — committed to yaacovCR/graphql-tools-fork by hwillson 5 years ago
- feat(errors): Pass through all possible errors. Use new relocatedError function to update the original GraphQLErrors with the new path. Addresses #743, #1037, #1046, apollographql/apollo-server#1582. — committed to yaacovCR/graphql-tools-fork by hwillson 5 years ago
- feat(errors): Pass through all possible errors. Use new relocatedError function to update the original GraphQLErrors with the new path. Addresses #743, #1037, #1046, apollographql/apollo-server#1582. — committed to yaacovCR/graphql-tools-fork by hwillson 5 years ago
- feat(errors): Pass through all possible errors. Use new relocatedError function to update the original GraphQLErrors with the new path. Addresses #743, #1037, #1046, apollographql/apollo-server#1582. — committed to yaacovCR/graphql-tools-fork by hwillson 5 years ago
Here’s a runnable reproduction that demonstrates this issue: https://github.com/hwillson/graphql-tools-stitching-errors
I’m working on a fix now, and will have it ready shortly.
Gonna try to fix this today! Starting to try to unpack the error handling stuff at the moment.
Figured I’d chime in here. I’m running into the scenario where we’re losing all errors and getting a message of
[Object object]when resolving through stitching, and I think it’s related.We’ve got the following architecture:
So if our clients hit the
Main GraphQLdirectly, we see everything as expected. If they then hit theProxy GraphQL(needed for some augmentation / stitching other sources) we only get backWhat’s interesting is that if we provide
formatErrorin theMain GraphQL’sApolloServerand we delete the theextensionsproperty on the default payload there, everything works as expected.I need to read more about how the format of those errors should be, but figured it was interesting enough to provide
@AdelBachene I had the same issue but my orignal error was nested deeper. I posted my solution here:
https://github.com/apollographql/graphql-tools/issues/480#issuecomment-418655377
This is where the error loses additional context, at least in my particular case: https://github.com/apollographql/graphql-tools/blob/master/src/stitching/errors.ts#L98-L108. I don’t know enough about apollo-link-http and http-link-dataloader, but I think that comment only applies to the condition for is singular in length and hasResult, which
apollo-errorinstances at least do not pass.So, there’s the conceptual issue of trying to throw a singular error for multiple instances as a
CombinedError. That might be the intended approach, but it definitely breaks the consumer’sformatError, unless I’m missing the part wherethis.errorsis parsed out into multiple errors again.Can’t the error instances just be returned as the
errorskey and graphql will propagate them up correctly? Isn’t that essentially the point ofannotateWithChildrenErrorsjust above this? But, take all this with the grain of salt that I’m just starting to look into itSeems like this is only happening when there are multiple errors thrown in the resolvers. What is the ETA on this? Seems like multiple persons have tried to fix this but nothing has happened?
Seeing this as well, and it severely affects the development experience when using graphql with schema stitching.
Solved this by switching to using graphql-tools-fork in our gateway until @yaacovCR’s PR has been merged. Didn’t need to change anything other than package.json and all the imports of graphql-tools, and worked like a charm. Thank’s mate!
@stubailo Hey Sashko!
Just a background info: in my case I have a GraphQL microservice-based architecture and a gateway that merge all my schemas in front of the microservices which is my GraphQL exposed API. But in this merge step, the schema stiching swallows the original error so it’s almost impossible to debug an error (no stack trace).
We recently released an alpha version of GraphQL Tools (#1308) that should fix the issue.
Please update
graphql-toolstonextor run:Let us know if it solves the problem, we’re counting for your feedback! 😃
Hi, I had the same issue. I managed to resolve it by using the workaround what @smber1 and @Pajk recommended in the threads:
Currently my introspection.ts looks like this: https://gist.github.com/szaza/12b079129283197036bcf96124b0af10;
I’ve also had to format the error messages in the child nodes and the root node like this: https://gist.github.com/szaza/2966f8c22b2205330e9b9d3d0835a541
@OlivierCuyp Nice, good use of the recursive function Thanks for sharing