apollographql / apollo-client

:rocket:  A fully-featured, production ready caching GraphQL client for every UI framework and GraphQL server.
https://apollographql.com/client
MIT License
19.38k stars 2.66k forks source link

`ApolloError.graphQLErrors` are not of type `GraphQLError` #11787

Open simPod opened 7 months ago

simPod commented 7 months ago

Issue Description

I'd like to resurrect https://github.com/apollographql/apollo-client/issues/11168 since issue got stale and closed.

As you can see in the graphql spec, the errors returned by the server are not required to specify e.g. extensions key.

However,

import type { GraphQLError, GraphQLErrorExtensions } from "graphql";

...

export type GraphQLErrors = ReadonlyArray<GraphQLError>;

export class ApolloError extends Error {
  ...
  public graphQLErrors: GraphQLErrors;

if you look at the GraphQLError class, the extensions field is not optional

https://github.com/graphql/graphql-js/blob/8e9813f8c283d94da66fad6fd9562432846c17d4/src/error/GraphQLError.ts#L89

  /**
   * Extension fields to add to the formatted error.
   */
  readonly extensions: GraphQLErrorExtensions;

That is achieved by taking server response and routing it through GraphQLError class' constructor:

https://github.com/graphql/graphql-js/blob/8e9813f8c283d94da66fad6fd9562432846c17d4/src/error/GraphQLError.ts#L125

    this.extensions = extensions ?? originalExtensions ?? Object.create(null);

So that implies that using GraphQLError[] as a type for ApolloError.graphQLErrors is wrong since the server data were not manipulated and may not comply with the GraphQLError interface.

Link to Reproduction

https://spec.graphql.org/October2021/#sec-Errors.Error-result-format

Reproduction Steps

No response

@apollo/client version

3.9.1

simPod commented 7 months ago

In tests it's done correctly https://github.com/apollographql/apollo-client/blob/65b4ba91de2415106e2327ae9f476c1d6f28f7e4/src/react/hooks/__tests__/useBackgroundQuery.test.tsx#L4395

phryneas commented 7 months ago

Thank you, that's a very good writeup and it's clear that we have to change something.

We're still undecided if we'll solve this in runtime or by adjusting our types, but I've opened #11789 to help us along with the decision process here.