Apollo-client: client.resetStore() does not clear data out of cache

[tsnieman]

Intended outcome:
Calling client.resetStore() should clear all data out of the cache.

Actual outcome:
Calling client.resetStore() does not clear data out of cache

How to reproduce the issue:
Call client.resetStore() and then inspect the cache.

Version

• apollo-client@2

Related info can be found here: https://github.com/apollographql/react-apollo/issues/807 - I created a new issue since the Stale Bot closed the old one. The old issue has much more information.

[jbaxleyiii]

@tsnieman do you have a reproduction I can use to fix / test against?

[jamesreggio]

@jbaxleyiii, we're experiencing this too, so I put together a repro.

Please see the repro-2411 branch on this repo: https://github.com/jamesreggio/react-apollo-error-template/tree/repro-2411

The expected behavior is for the existing data to be cleared immediately upon pressing 'Reset Store' — however, instead, the data remains and no updates are received until the query has finished refetching from the server.

[jbaxleyiii]

@jamesreggio thanks! I'll have this fixed today!

[jbaxleyiii]

@jamesreggio is that how it happened on the 1.0? I'm wondering if we are missing a broadcast call, but I do seem to remember this being by design on the 1.0 to not clear out the UI during resetStore. So looking at your reproduction it seems to be working as expected?

[jamesreggio]

I'm not certain what the behavior was in 1.0; however, if this is intended behavior, I found this documentation a bit misleading:

resetStore(): Promise | Promise
Resets your entire store by clearing out your cache and then re-executing all of your active queries. This makes it so that you may guarantee that there is no data left in your store from a time before you called this method.

I assume the clearing cache + re-executing all active queries = broadcast to all observers with loading: true and empty results. The lack of even a loading: true broadcast is going to force me to do quite a bit of external gymnastics to ensure that our user isn't returned to a view filled with data belonging to the prior user, unless there's another way I could observe the reset.

If, in the interest of backwards compatibility, the default behavior remains like this, perhaps you should add a boolean flag (forceBroadcast?) to 'flush' the reset through all of the observers? It appears that there's a lot of people chiming in on https://github.com/apollographql/react-apollo/issues/807 with expectations similar to mine.

[jbaxleyiii]

@jamesreggio yeah totally! I think that #807 shows the disconnect between what happens and the expectation / docs are an issue to be addressed!

[stantoncbradley]

client.cache.reset() will actually clear the cache
Akryum/vue-apollo#53 (comment)

[amityo]

@stantoncbradley thanks. be aware that onResetStore promise run only on resetStore

[jamalx31]

calling client.resetStore() from inside Query works.
calling the same function outside of it by importing the client directly doesn't.

[hwillson]

https://github.com/apollographql/apollo-client/pull/3885 adds a new client.clearStore() method to the public API, that will clear the store without refetching active queries. Thanks!

[nomadoda]

client.cache.reset() will actually clear the cache
Akryum/vue-apollo#53 (comment)

This doesn't clear the cache for me

[ptimson]

@nomadoda me neither - did you find a work around?

[nomadoda]

@ptimson This is what I found in my old project. Unfortunately I can't confirm whether it works or not, but maybe it can be to some help.

  import { apolloClient as apollo } from '@/apollo/client';
  import { stateLink } from '@/apollo/link/state';

  async function logout() {
    try {
      await apollo.mutate({
        mutation: LOGOUT_MUTATION,
        fetchPolicy: 'no-cache',
      });
    } finally {
      await apollo.clearStore();
      await stateLink.writeDefaults();
    }
  }