errors plugin and apollo server errors

[mmahalwy]

Sorry for the bothersome question but trying to wrap my head around how this would work with apollo server's errors and apollo client's error link.

Apollo catches errors when there is a returned errors array in the response. Meanwhile, the plugin error resolves the query but returns a union with errors (when that error is thrown). We end up getting a weird split in code where a query that contains authorization will throw unauthorized via apollo-server but if has a zod error, for example, will resolve with the errors in the body. This doesn't get caught by apollo-error-link (unlike the authorization error) because it technically resolves.

Thoughts on how to unify the two? Ideally, plugin errors would be treated as apollo-server errors on the client side. Curious how you've set it up for your projects.

Here's our apolloClient:

const authLink = new ApolloLink((operation, forward) => {
  operation.setContext(({ headers = {} as { [key: string]: $TsFixMe } }) => {
    // @ts-ignore
    const cookies = new Cookies();
    const accessToken = cookies.get('jwt2');

    return {
      headers: defaults(headers, {
        authorization: accessToken ? `Bearer ${accessToken}` : '',
        'sentry-trace': uuidv4(),
      }),
    };
  });

  return forward(operation);
});

const sentryLink = new SentryLink({
  breadcrumb: {
    includeQuery: true,
    includeVariables: true,
    includeError: true,
    includeResponse: true,
    // includeCache: true,
  },
});

const httpLink = new HttpLink({
  uri: `${API_URL}/api/graphql`,
  fetch,
});

const createLink = () => {
  const errorLink = onError(({ operation, networkError, graphQLErrors, forward }) => {
    if (networkError) {
      const content = `[GraphQL error]: ${networkError.name} Message: ${networkError.message}, Stack: ${networkError.stack}`;
      console.error(content);
      if (IS_DEV) {
        message.error(content);
      }
    }

    if (graphQLErrors) {
      graphQLErrors.forEach(({ message: gMessage, locations, path }) => {
        const content = `[GraphQL error]: Message: ${gMessage}, Location: ${locations}, Path: ${path}`;
        console.error(content);
        if (IS_DEV) {
          message.error(content);
        }
      });
    }

    return forward(operation);
  });

  return from([authLink, sentryLink, errorLink, apolloLogger, httpLink]);
};

const typePolicies: TypedTypePolicies = {
  ApplicationFormFieldConfig: {
    keyFields: ['name', 'label'],
  },
  ApplicationFormConfig: {
    fields: {
      fields: {
        merge: false,
      },
    },
  },
};

export const createApolloClient = (options: Options) =>
  new ApolloClient({
    ssrMode: typeof window === 'undefined',
    link: createLink(),
    cache: new InMemoryCache({
      possibleTypes: possibleTypes.possibleTypes,
      typePolicies,
    }),
  });

[mmahalwy]

One thought is to eliminate the possibility of having errors not handled by error plugin by doing:

const builder = new SchemaBuilder({
  plugins: [ErrorsPlugin],
  errorOptions: {
    defaultTypes: [Error, ApolloError],
  },
});

to catch all. That way, we will always return a union for all mutations and queries.

[hayes]

@mmahalwy I don't think that will work, generally you won't be throwing an apollo error inside you resolvers, so the errors plugin would not catch those errors.

There are effectively 3 options:

1. Move everything that can throw into your revolvers (including authentication, authorization), not sure if this is already what you are doing. And then add handling and then use the errors plugin on every field/query/mutation that can throw, and have everything become a union. I personally don't love this approach, because it kinda bloats your schema, and clients will likely implement some generic handling that doesn't take advantage of the errors being typed anyway.
2. Don't use the errors plugin. Errors plugin is just one way to handle errors, and apollo has a decent amount of tooling around it already to handle errors thrown using the default behavior.
3. Only use the errors plugins for known/common errors, or specific errors you want to handle client side. This is probably the approach I would take. Recoverable, common, or expected errors are handled by the errors plugin, clients then implement UI to handle these cases, and they are not "errors" on the client side and wouldn't need to be logged, since they are not "exceptional" from the client perspective.

Generally I would think about why you are trying to do with your error logging. I generally wouldn't want to rely on client reporting of server errors, and instead would want the server to log when things go wrong server side. For client side errors, I would probably want to report network errors, or errors that are not expected/handled by the client, which are generally not the cases you would handle with the errors plugin.

Not sure if that's helpful 🤷

One feature I could see coming out of this, is a hook for logging errors handled by the errors plugin, which i don't think exists today

[mmahalwy]

@hayes thanks for the detailed answer! I think we are going to go with option 3 as it wont force us to migrate everything over to errors plugin (option 1) and still benefit from the errors.

In terms of hook - do you mean a react hook or an apollo link?

[hayes]

I mean a callback triggered server side when errors are handled by the error plugin. Probably passed in to the config options for the builder