apollo-client: graphQLErrors not populated in thrown ApolloError during 400 NetworkError

The graphQlErrors property of ApolloError is not populated with the error details when a schema required field is not supplied during a mutation. However, the error is sent correctly to onError().

Intended outcome: ApolloError.graphQLErrors to be populated with the GraphQL error information

Actual outcome: ApolloError.graphQLErrors is an empty array

How to reproduce the issue:

Begin with the schema:

type Mutation {
  someAction(requiredParam: String!): Boolean
}

Use apolloClient.mutate(...) to call someAction without specifying the requiredParam
In the thrown ApolloError, only the networkError property is set.
- The networkError is: ServerError: Response not successful: Received status code 400.
- The graphQLErrors is not set.
However, when using onError in apollo-link-error, both the networkError and the graphQLErrors properties are populated correctly.

Versions

  System:
    OS: Linux 4.19 Ubuntu 18.04.3 LTS (Bionic Beaver)
  Binaries:
    Node: 12.13.0 - /usr/bin/node
    Yarn: 1.22.4 - ~/.yarn/bin/yarn
    npm: 6.12.0 - /usr/bin/npm
  Browsers:
    Chrome: 81.0.4044.113
  npmPackages:
    apollo-cache-inmemory: ^1.6.5 => 1.6.5
    apollo-client: ^2.6.8 => 2.6.8
    apollo-link-error: ^1.1.13 => 1.1.13
    apollo-link-http: ^1.5.17 => 1.5.17
    apollo-server: ^2.12.0 => 2.12.0

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 4
Comments: 16 (6 by maintainers)

Most upvoted comments

I can confirm that this happens in version 3.2.5 as well. The graphQLErrors are present in custom the onError(({ graphQLErrors, networkError }) link, but when it is read within the error object via a useMutation hook within a component, it is set to an empty array [] 😢 graphQLErrors_Empty

r0ughnex on Oct 26, 2020

@hwillson Here it is: https://codesandbox.io/s/hardcore-snyder-kifgs?file=/src/App.js

If you were to add an ErrorLink into the ApolloClient you would also see that GraphQLErrors is correctly populated. It’s only after the errors get basically wrapped by a ServerError in HttpLink they get lost deeper down in the error object.

ParallelUniv3rse on May 6, 2021

I just upgraded to 3.4.7 and I’m still seeing this issue.

Here’s the error’s stack trace:

Error: Response not successful: Received status code 400
    at new ApolloError (index.ts:56)
    at Object.error (QueryManager.ts:307)
    at notifySubscription (module.js:137)
    at onNotify (module.js:176)
    at SubscriptionObserver.error (module.js:229)
    at Object.error (asyncMap.ts:48)
    at notifySubscription (module.js:137)
    at onNotify (module.js:176)
    at SubscriptionObserver.error (module.js:229)
    at iteration.ts:13
    at Array.forEach (<anonymous>)
    at iterateObserversSafely (iteration.ts:13)
    at Object.error (Concast.ts:185)
    at notifySubscription (module.js:137)
    at onNotify (module.js:176)
    at SubscriptionObserver.error (module.js:229)
    at Object.error (index.ts:77)
    at notifySubscription (module.js:137)
    at onNotify (module.js:176)
    at SubscriptionObserver.error (module.js:229)
    at createUploadLink.js:230

The error originates here: https://github.com/apollographql/apollo-client/blob/c550c57135e7293897ab4038cff43f655dcd0835/src/link/http/parseAndCheckHttpResponse.ts#L30-L37

Then it’s wrapped here: https://github.com/apollographql/apollo-client/blob/c550c57135e7293897ab4038cff43f655dcd0835/src/core/QueryManager.ts#L306-L308

I can access the graphql errors by accessing error.networkError.result.errors.

stephenbunch on Aug 11, 2021

Any chance you could provide a small runnable reproduction that shows this @TriPSs?

hwillson on May 4, 2021

This is still the case with 3.3.16 @hwillson.

TriPSs on May 3, 2021