apollo-client: Error is not retrieved from the cache

I have been trying to implement a standard UI where a particular resource can be found on a path like this /user/:id. If I try to access a user that I don’t have permissions to I expect server to return an error and a user node to be null. However if I try to access the same resource again, user will be retrieved from the cache even though it’s null but error field is undefined - that prevents me from reacting to the data correctly as I don’t know on the second pass whether null means an error and what kind of error since error field is not present. The first request gives me correctly user and error.

Is it possible to setup cache policy to either not store null resources when errors are present or make sure that errors are cached as well?

My Setup:

const cache = new InMemoryCache();
const defaultOptions = {
    watchQuery: {
        fetchPolicy: 'cache-first',
        errorPolicy: 'all'
    },
    query: {
        fetchPolicy: 'cache-first',
        errorPolicy: 'all'
    },
    mutate: {
        errorPolicy: 'all'
    }
};
const client = new ApolloClient({
    shouldBatch: true,
    link: ApolloLink.from([new HttpLink({ uri: GRAPHQL_ENDPOINT })]),
    cache,
    defaultOptions
});

Thank you!

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 24
Comments: 38 (1 by maintainers)

Most upvoted comments

It would be nice for this issue to be looked into or for the docs to be updated to remove the false claims of what this repository is able to achieve.

I understand this is a bug and should be resolved rather than being removed from the documentation, but this has not been looked into for 8 months and the documentation has not been amended so people are evidently getting confused over it.

I just wasted several days work because I assumed this would work. Now I have had to delete much of my recent work and build my own custom store as a hacky way of storing errors until this is fixed.

Thomas-Smyth on Jul 14, 2019

Any updates on this? The problem seems quite major to me.

dulakm on Sep 10, 2019

Facing the same issue currently, we’re using graphql-shield which throws an error when a permission check isn’t met. Apollo caches the result as null but doesn’t cache the error.

In the docs it mentions that errors should be cached, so I’m guessing this used to work. "it saves both data and errors into the Apollo Cache so your UI can use them."

Also it looks like deafultOptions aren’t respected anyway #2555, #3256, however setting errorPolicy: 'all' on the query works, just a pain to set it on every query that may throw an error.

You can make this work by using the following, however it’s just skipping the cache and ignoring the issue entirely.

errorPolicy: 'all',
fetchPolicy: 'no-cache',

maxlew on Nov 21, 2018

I am using useQuery . I set errorPolicy: “all” . I have 2 queries in a query . Eg . const GET_MULTI_QUERY = gql query GetMulti { ldapGroups(email: "myemail") listQueues(request: {}) { queues { uuid version name } } };

Now if one of them errors out , I expect to get data for the other one as well as get the error with what has been said in the documentation . However, I am not getting the error . I get error as undefined . I tried errorPolicy: ‘none’ , this sets data to null and only gives the error . Also, errorPolicy: ‘ignore’ does not work . I am using SSR but that should not matter .

This is a long thread and I guess the expectation is get the error as well as the data possible .

Any progress or anyone working on this ? This looks like a very basic requirement as the playgroung even works like that .

ankitjaincst on Nov 5, 2019

Currently my error policy is "all" which is what i need / would expect. Whats happening is the first request gets the error and data: null when i hit back and then go back to the page it simply pulls data: null from the cache as the original issue describes.

joepuzzo on Mar 25, 2019

Same issue. We have a query that we don’t want to throw an exception during a server side render. Setting the errorPolicy to ‘all’ solves this, but the error is never sent to the client’s Query component. Setting the fetchPolicy to no-cache does work, but it also causes the query to be re-issued.

mikebm on Jan 22, 2019