apollo-client: graphQLErrors is empty in promise chain
i am using apollo-client@2.0.4 standalone with the basic setup:
const graphLink = new HttpLink({ uri: 'http://localhost:4001/graphiql' })
const errorLink = onError(({ graphQLErrors }) => {
if (graphQLErrors) {
graphQLErrors.map(
({ message, path, detail }) =>
> graphQLErrors has value here
debug(`[GraphQL error-- ]: ${path} ${message} ${detail}`)
)
}
})
const link = ApolloLink.from([errorLink, graphLink])
const client = new ApolloClient({
link,
cache: new InMemoryCache(),
})
the graphQLErrors result in onError block is right. this is the grahql-playground result:
but the graphQLErrors is empty in the promise-catch block
const QUERY = `
{
allUsers2 {
entries {
username
}
totalCount
pageSiz
}
}
`
const query = gql`
${QUERY}
`
client
.query({
query,
context,
})
.then(data => {
debug(data)
})
.catch(({ graphQLErrors, message }) => {
if (graphQLErrors) {
> graphQLErrors is Empty here
/* debug('【catch graphQLErrors:】 ', graphQLErrors) */
}
})
About this issue
- Original URL
- State: open
- Created 6 years ago
- Reactions: 19
- Comments: 28 (1 by maintainers)
I found simple fix:
err.networkError.result.errors
, invoking it in catch() handlers will fix problemThanks for reporting this. There hasn’t been any activity here in quite some time, so we’ll close this issue for now. If this is still a problem (using a modern version of Apollo Client), please let us know. Thanks!
I just posted last month and it’s still a problem. I don’t think this issue should be closed.
+1 please re-open, still seeing this behavior in latest the version
+1 problem is still here
@apollo/client@3.0.0-rc.10
graphQLErrors
array is empty, butnetworkError.result.errors
has GraphQL errors.After a bit of further reading… (https://www.apollographql.com/blog/full-stack-error-handling-with-graphql-apollo-5c12da407210)
A graphQLError is an error that occurs in a resolver, a networkError happens outside a resolver:
By that definition I don’t have a bug, but perhaps renaming the fields might help make this less of a foot gun? Maybe rename
graphQLErrors
toresolverErrors
so that (for those of us who don’t read all the docs) we don’t mistake parsing/validation errors for resolver errors.Unfortunately 95% of the Github issue emails I get are from people like me running into issues with this library. You may consider using a different tool like urql or writing raw GraphQL queries/mutations paired with something like react-query to handle caching and request state.
I’m also running into this. Should a new issue be opened?
any updates?
@Mati365 the error should be in graphQLErrors, in my case if the error is from the resolver graphQLErrors is not empty but when the error come from apollo-server-express context the error is in networkError. and graphQLErrors is empty!
That does not make sense and I don’t want to handle 2 cases in my catch statement!
This problem is still there. Edit: Switching to react-query fixed the issue
@marhub and it will exist forever because maintainers seem to ignore bug reports (meanwhile focusing on creating new features with breaking changes)
???
I too am experiencing this problem today All the errors returned from GQL are populated in the networkError property as opposed to the graphQLErrors array when using a mutation.
Edit: I am now extracting errors with some custom functions
I’m also seeing this issue. My server returns a 400 response that looks like:
The
onError
middleware correctly passes this through in thegraphQLErrors
array (along with anetworkError
), but by the time it gets to the Mutation component’serror
object,graphQLErrors
is an empty array. Theerr.networkError.result.errors
trick works but is hacky. Any thoughts?