Apollo-client: refetch does not replace the original cache

[linxianxi]

Did you rewrite refetch?
I tried v3.1.3 and v3.2.0-beta.6

[linxianxi]

I tried version 2, is OK! Version 3 doesn't work！

[linxianxi]

I only used cache.writequery when adding data, delete did not。

After the first request, a piece of data is deleted, and the original cache is replaced after the refetch. If it is not on page 1, it will not jump to page 1. Version 2 will jump to page 1.

After the first request, add a piece of data, add it to the cache, and then delete it. The data requested by a refetch does not replace the current cached data. Note: Deletion does not use writeQuery. Fetch replaces the cache if the data is deleted from the request and not just added to the cache.

In version 2, in all cases the refetch jumps to the first page and replaces the original cache

[anasqadrei]

I have the same issue. Refetch doesn't reset cache (which I believe it should). My case is similar to code in this question:

https://stackoverflow.com/questions/63108804/rn-apollo-client-3-0-handle-refetch-with-merge-function

[linxianxi]

Refetch should refetch the request and replace the cache.

Instead of refetch, I temporarily use window.location.href = window.location.href

[nhanpdnguyen]

I think I have the same issue:

• I used useQuery and refetch (in useEffect) in 1 component to fetch the data.
• In another component, I used readQuery to read the cache but the cache is not getting updated properly, sometimes it is but sometimes it is not (look likes having some kind of race conditions)

[linxianxi]

@benjamn

[BowlingX]

Same issue here with v3.1.3 and the following query configuration:

    fetchPolicy: "cache-and-network",
    nextFetchPolicy: "cache-first",

refetch will not update the cache (but do a network request),
In my case it only affects queries that where modified with writeQuery and updated (with optimisticResponse).
Queries that where not modified and and refetched worked.

[BowlingX]

As a workaround you can use fetchMore with the same variables. this worked for me.

[dallonf]

fetchMore also helped me in what seems to be a similar situation! Would love to see refetch fixed though. Seems that the data it retrieves isn't even sent to my merge field policy.

[benjamn]

@linxianxi What approach are you using to delete the data, if not writeQuery? Also, how long after the initial request are you doing the refetch? Like, immediately, or in response to user input, or something else?

[linxianxi]

@linxianxi What approach are you using to delete the data, if not writeQuery? Also, how long after the initial request are you doing the refetch? Like, immediately, or in response to user input, or something else?

Add a piece of data using writeQuery, and then initiate a request to delete a piece of data, without changing the cache, and use refetch to retrieve the data

[anasqadrei]

In one of my cases, I query a listComments in one of the components. When a user clicks to delete a comment in another component, I initiate a mutation deleteComment with listComments in the refetchQueries and awaitRefetchQueries: true.

In the merge function, I find the existing = list of comments _with_ the deleted comment and incoming = list of comments _without_ the deleted comment. I end up with duplicate objects.

Shouldn't incoming = null in this case?

[dallonf]

I used cache.modify to delete data, which caused the data in the React component to immediately disappear, as expected. Calling refetch caused a network request, but the data never made it back to the component - or, based on my logs, even to the merge function of the field that was deleted. writeQuery had similar results.

[gregoryforel]

@benjamn I have the feeling that it happens also with pollInterval.

1. Add data manually to the cache with writeQuery, to a query that has pollInterval set.
2. The polling should overwrite the cache, and remove the newly added data in step 1. But it doesn't.

Here is an example of this issue. I also added the refetch (does not replace original cache) / fetchMore (works) example described earlier in this thread.

codesandbox

[Badbreaddead]

I have this problem too. Is it going to be addressed any time soon? or should we use fetchMore?

[hinsxd]

Bump. Same issue here.

[charle692]

I don't think using fetchMore is a solution here. Semantically fetchMore suggests that we are going to be loading more data and appending it to the existing.

refetch should clear the cache or at minimum it should be detectable from inside the merge function so that we can manually omit existing cache entries.

I just ran into this while migrating away from the deprecated updateQuery and instead using a custom merge function.
I'm willing to help out and implement something if we can decide on a direction/intended behaviour for this.

[DavidGolodetsky]

Same issue

[gregoryforel]

I don't think using fetchMore is a solution here. Semantically fetchMore suggests that we are going to be loading more data and appending it to the existing.

refetch should clear the cache or at minimum it should be detectable from inside the merge function so that we can manually omit existing cache entries.

I just ran into this while migrating away from the deprecated updateQuery and instead using a custom merge function.
I'm willing to help out and implement something if we can decide on a direction/intended behaviour for this.

Agreed, it's a workaround. But so far, I haven't seen any other solution that works other than using fetchMore.
I'm surprised this isn't solved yet, as it wasn't an issue before hence is a newly introduced bug.

[JeffJankowski]

I'm surprised this isn't solved yet, as it wasn't an issue before hence is a newly introduced bug.

Agreed. I think these various regressions should be taking priority..

[SeanSanker]

Same issue here