Apollo-client: "GraphQL error" text string in error messages

[SachaG]

I've noticed that all error messages passed on from apollo-client include the string "GraphQL error":

https://github.com/apollographql/apollo-client/blob/a80ed36a76317d01009f0ff03ade340844d6e317/src/errors/ApolloError.ts#L20

I'm wondering if this is really necessary? It's not a big deal (I can remove the string myself manually) but in some cases you might want to show an error message from the server when (for example) a mutation fails, and users who know nothing about GraphQL might get confused (I've had reports of "some kind of OpenGL error"… ;) )

[stubailo]

You can retrieve the actual error message from inside the ApolloError object, the message is mostly intended to be a summary for developers and differentiates between a graphql error and a network error.

[SachaG]

Is that supposed to work inside errors resulting from mutations, too? When I log out error.message it still has GraphQL error: ....

[stale[bot]]

This issue has been automatically marked as stale becuase it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions to Apollo Client!

[jbaxleyiii]

@SachaG you can retrieve all of the GraphQL errors like this:

  .query({
    query: gql`
      query {
        viewer {
          login
        }
      }
    `
  })
  .then(data => console.error("TEST RES =>", data))
  .catch(error => {
    console.error("TEST ERR =>", error.graphQLErrors.map(x => x.message));
  });

If you take a look here and open the console to the Frame, you can see the actual issue reported by the server

[SachaG]

@jbaxleyiii I actually ended up using https://github.com/thebigredgeek/apollo-errors instead.

[runk]

+1

When you have server-side validation error it's intuitive to use just error.message - it feels wrong that there's implementation/technical detail being exposed to the user. Not sure there's a real value. IMO it'd be far better to swap that deep error with real message with modified one.

Or make the prefix configurable and set it to "GraghQL Error" by default. Happy to send a PR for it you it's something that's going to be accepted / not wasted.

[vmasto]

Not sure why this is closed, I've been dazzled by this for the better part of the day trying to remove the prefix.

The most common of use cases:

I fire a mutation from within a component in a try/catch statement. I just want to setState({ error: error.message }) in my catch. My GQL errors are already optimized for user display.

It's not hard to str.replace or introspect and get the original error for a couple of components but on a big app it's unmaintainable to have to do it everywhere manually.

[RDGthree]

Gonna throw in another vote for removing this string, it results in GraphQL error: [Object object] if you have errors with multiple fields. This is broken, bizarre, unnecessary functionality.

[pcjmfranken]

For some reason mutations over websockets (subscriptions) don't return anything so I'm forced to run the mutation inside a try/catch block and parse the error from there. Unfortunately, this includes the silly 'Graphql error:' which I have to remove manually.

[asotog]

Same thing here, :(

[joepuzzo]

I am also having this issue.. Would it not make more sense to simply set error to the actual error?

[diegocouto]

I can see the value in differentiating GraphQL errors from network errors, but having to filter error.messages is very disappointing. 😞

[gregblass]

Google'd 'GraphQL error get message' and arrived here. Definitely unintuitive with the whole map thing. Error.message should return the actual message without the 'GraphQL Error:' part.

[danielmahon]

I agree this should be configurable/overridden somewhere (maybe through apollo-link-error?). I find myself writing message.replace('GraphQL error:', '').trim() alot...

[flux627]

Currently replacing the string myself manually too. This needs to be configurable.

[ropaillet]

Made a client side helper method to remove the string... Can anyone with the back knowledge push so they remove it ? User doesn´t care about GraphQl and having to make such implementations either on the client side or a custom server side error code makes no sense.

export function serverError(errorMsg) {
return errorMsg.replace('GraphQL error:', ' ').trim();
}

Specially important for login and signup mutations where you use server side REGEX to validate inputs and throw errors if it fails.

[Undeadlol1]

Seriously, please fix.

[JustinPlute]

+1

[xenovon]

At first i thought this one coming from backend (i'm frontend guy). I get some complain from the user why error message contain this cryptic string that they don't understand (obviously they don't know what graphql is). I told backend team to change it, until they send link of this issues.

Okay, then my fate has been sealed to fix this issues.

I think this one need to be removed. If there some need to add this string for debugging process, we can always add additional variable for it.

[smschick]

+1

[k00k]

I think the ability to customize/overwrite the error message would be well-placed into apollo-link-error. Currently adding apollo-link-error to the client simply logs the error to the console, it doesn't propagate through to the error callback. Perhaps there's a way to do this already?

[venkat4541]

I think this is more of a GraphQL issue rather than Apollo but I may be wrong. I would try to get response from GraphQL team rather. But this issue is causing a headache on front-end.

Anyone found any way around to change the string to an object?

[giraudvalentin]

Why this is closed ?

[sunstorymvp]

At least "GraphQL error: " prefix should be added before apollo-link-error so it is possible to get rid of it in one place...

[stolinski]

I'm also wondering why this was closed.

[hwillson]

I think it's safe to say that the community has spoken on this one, and that we should start looking into a different approach here. I've re-opened this issue - thanks all!

[lorensr]

[Object object]

I've seen GraphQL error: [Object object] before, but I don't remember why. @RDGthree—you said it's caused by multiple fields with errors, but I'm unable to replicate that. I'm seeing error.message as:

GraphQL error: message from field1
GraphQL error: message from field2

https://codesandbox.io/s/4xn6pyl1r9

One thing that does cause it is creating an error with an object message, but that's how JS works:

You'd have to stringify first:

Stripping prefix

I don't imagine devs wanting to show network errors, only graphql errors? In which case we could leave in the network prefix if we wanted? So error.message would be:

• One graphql error:

message from field1

• Two graphql errors:

message from field1
message from field2

• Two graphql errors and one network error (is this possible? the code at least currently covers this case)

message from field1
message from field2
Network error: sorry, your cable got cut

Or we could prefer consistency and strip Network error: as well:

message from field1
message from field2
sorry, your cable got cut

Thoughts?

[hwillson]

To help provide a more clear separation between feature requests / discussions and bugs, and to help clean up the feature request / discussion backlog, Apollo Client feature requests / discussions are now being managed under the https://github.com/apollographql/apollo-feature-requests repository.

Migrated to: https://github.com/apollographql/apollo-feature-requests/issues/46