apollo-client: Unable to handle errors in local state management

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.

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.

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

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

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?

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?

Hey everyone, I did some testing with Apollo Client 2.6.8 and it appears to be working now!

We’re trying to do more or less the same thing in our project, and it seems to be broken in 2.6.8 still, is there an ETA for @asselstine 's PR or another working solution? 😃

@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;
    };
  }, []);

A lot of the Apollo Client internals have changed since v3 was launched. We recommend trying a more modern version of @apollo/client. Let us know if you’re still encountering this issue. Thanks!

It seems like everyone has different permutations of this issue.

What I am seeing:

1. local mutation resolver throws an error
2. error gets passed to the react component and rendered
3. immediately after, the error bypasses the error link and the app crashes because of “Unhandled Rejection (Error): Network error: …”

When performing a query that does a network request (to my graphql server), expected errors are successfully handled by the error link.

I was hoping to use apollo for this new project, but I think I may switch to a simpler tool and revisit when this product is more stable.

Hey everyone, I did some testing with Apollo Client 2.6.8 and it appears to be working now!

What I did:

1. Create local state resolvers
2. Throw an error in the resolvers
3. The component can see the error, i.e. const { data, loading, error } = useQuery(…)

So…all is well now? Perhaps just upgrade everyone!

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?

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.