Unable to handle errors in local state management

[lfades]

Intended outcome:

The following @client only query:

const GET_COUNT = gql`
  query GetCount {
    count @client
  }
`;

<Query query={GET_COUNT}>
  {({ loading, error, data }) => {
    if (loading) {
      return <p>Loading GET_COUNT query</p>;
    }
    if (error) {
      return <p>An error ocurred: {error.message}</p>;
    }
    return <p>Page ready</p>
  }}
</Query>

Should be capable of handling an error returned by the resolver:

const resolvers = {
  Query: {
    count() {
      throw new Error('Oh no!')
    }
  }
};

Actual outcome:

The query renders again with error set with the thrown error, but it renders again immediately after with error as undefined, so It's not possible to actually handle the error.

How to reproduce the issue:

I created a repo showing the error, which also shows a error with apollo dev tools: https://github.com/lfades/apollo-state-issue. It's important to notice that I'm not using a GraphQL backend and just using local state management.

Versions

Check the versions in the repo 🙏

Thank you.

[bbruneau]

All errors thrown in a client side reducer register as network errors. They seem to be cleared when the query is marked as complete. Is there a way to return a GraphQLError from the custom resolver?

[jounii]

Right now trying to figure out this myself too. I can throw errors fine, but the response data shows up as "null" and can't find way to pass the error up back to the query part. I have also tried throwing ApolloError and extends of those (with custom messages).

Also tried onError link for the client.

Case is that the resolvers use outside API to fetch data, but can't figure out way to inform query caller that the API is unavailable (ie. authentication issue).

Thinking about hacking error passing to custom context, not ideal but doable.

[tbrannam]

I'm seeing the same - in my case I'm attempting to implement a local resolver that passes additional data to a remote graphql query - and if the remote fails, I can't percolate the error back to the caller.

[boennemann]

Hey all,

For any production application missing error handling is a total blocker.
With the present behavior it's impossible to use local state management at all.

Is there any update, or a work around for this? Or maybe a pointer on where one would start working on a fix?

Thanks,
Stephan

Edit: For anyone else coming here: Moving back to https://github.com/apollographql/apollo-link-state works.

[brandonmp]

Adding to the pile: I have a case where the resolver fails at initial page load, but succeeds on subsequent calls of that Query.

The end result is that the data prop remains undefined, even when the resolver is successfully resolving and returning the correct data.

In other words, it seems like once a @client resolver fails once, that query returns undefined from that point on, even if the resolver succeeds.

Anyone else observing this?

[rdy]

We're running into the same issue actually. I may consider moving back to apollo-link-state just to get reasonable error messaging.

[asselstine]

Reverting back to apollo-link-state worked for me. The only downside is that Apollo spits out:

Found @client directives in a query but no ApolloClient resolvers were specified. This means ApolloClient local resolver handling has been disabled, and @client directives will be passed through to your link chain.

Apparently it's harmless.

🤷‍♂

[ryaninvents]

I'm encountering the same issue. If I understand correctly, the fix would be to add a catch to this promise continuation. Let me know if a PR would be welcome on this; I'd be happy to contribute.

If there were a documented method for writing errors directly to the cache, that could be a feasible short-term workaround.

[layerssss]

@asselstine Monkey-patch console.warn to ignore this message, if you fancy

  useEffect(() => {
    const _oldConsoleWarn = console.warn;
    console.warn = (...args) => {
      if (args[0]?.constructor === String) {
        const message = args[0];
        for (const prefix of [
          "Found @client directives in a query but no ApolloClient resolvers were specified.",
        ]) {
          if (message.startsWith(prefix)) return;
        }
      }
      _oldConsoleWarn.apply(console, args);
    };
    return () => {
      console.warn = _oldConsoleWarn;
    };
  }, []);

[Zdend]

I'm encountering the same issue. If I understand correctly, the fix would be to add a catch to this promise continuation. Let me know if a PR would be welcome on this; I'd be happy to contribute.

If there were a documented method for writing errors directly to the cache, that could be a feasible short-term workaround.

This seems to be the real solution. Thanks

[cruhl]

Just ran into this today, this is an absolute requirement for local state management.

[tbrannam]

I'm encountering the same issue. If I understand correctly, the fix would be to add a catch to this promise continuation. Let me know if a PR would be welcome on this; I'd be happy to contribute.

If there were a documented method for writing errors directly to the cache, that could be a feasible short-term workaround.

I'm encountering the same issue. If I understand correctly, the fix would be to add a catch to this promise continuation. Let me know if a PR would be welcome on this; I'd be happy to contribute.

If there were a documented method for writing errors directly to the cache, that could be a feasible short-term workaround.

Did you push a PR?