Cache.evict triggering an unintended network query

[stoickeyboard]

Hi, I'm trying to delete a comment from a list in the cache by filtering out the comment and then using cache evict. I'd expect this to all be done without an additional query to the network. However, that is not the case. Calling cache.evict() triggers a network query for the comment list. If I don't call cache.evict() and instead only filter the comment out of the list, an additional network call is not triggered. When I look at APOLLO_CLIENT.cache.data.data, I can see that the comment was actually filtered from the list.

Intended Outcome: Filter Comment from comment list and use cache.evict() to delete comment from cache without additional network query to retrieve the comment list (without deleted comment).

Actual Outcome: Filter Comment from comment list and use cache.evict() to delete comment from cache and also query the new comment list from the network as a safety check

Here's what my update function looks like:

update(cache, { data: { manageComment } }) {
const data = cache.readQuery({
query: FETCH_COMMENTS,
variables: {post_id},
})

  //Filter out deleted comment
  cache.writeQuery({
    query: FETCH_COMMENTS,
    variables: {post_id},
    data: {
      comments: data.comments.filter(
        (comment) =>
          comment.comment_id !== manageComment.comment_id
      ),
    },
  })

//Delete comment from cache
 cache.evict({ id: cache.identify(manageComment) })

} catch (err) {
  console.log(`Couldn't find comment list query for post ${post_id} `)
}

}

To reproduce the issue, I assume you can just call cache evict and see if a network query is called. I believe this is a bug because I don't see the point of messing with the cache if we're going to refetch as a safety check anyway but maybe I'm wrong. Thanks Apollo team for everything you've done! I appreciate it!

I also tried to filter out the comment in the typePolicies like so but that did not seem to help:

Query: {
fields: {
comments(existingComments, { canRead }) {
return existingComments
? existingComments.filter(canRead)
: []
},
comments: {
keyArgs: ['post_id'],
},
},
},

Versions
System:
OS: macOS Mojave 10.14.6
Binaries:
Node: 11.12.0 - /usr/local/bin/node
Yarn: 1.2.1 - /usr/local/bin/yarn
npm: 6.7.0 - /usr/local/bin/npm
Browsers:
Chrome: 84.0.4147.105
Safari: 13.1.2
npmPackages:
@apollo/client: ^3.0.2 => 3.0.2

[KeithGillette]

I am attempting to migrate our project to Apollo Client 3 and seeing similar unwanted behavior when attempting to use cache.evict(). From what I understand in the comments on issue #6702, these network refteches seems to be by design and must be overridden using a different fetchPolicy or the new nextFetchPolicy option.

[stoickeyboard]

I am attempting to migrate our project to Apollo Client 3 and seeing similar unwanted behavior when attempting to use cache.evict(). From what I understand in the comments on issue #6702, these network refteches seems to be by design and must be overridden using a different fetchPolicy or the new nextFetchPolicy option.

Ahhh I see. I'll try that. Thanks for the response!

[KeithGillette]

You're welcome, @HummingBird24. I did a bit more work on this in our project and found that the nextFetchPolicy can be set globally when configuring Apollo Client. While I'm still working through migration issues in our project, the following appears to eliminate the unwanted automatic network refetches after using cache.evict():

new ApolloClient({
  defaultOptions: {
    watchQuery: {
      nextFetchPolicy: 'cache-only'
     }
  });

[gbilodeau]

@KeithGillette This indeed prevents automatic network refetches, but it also prevents you from doing an actual network refetch. I'm not sure how to work around this behavior.

[benjamn]

@KeithGillette @gbilodeau See #6893 for some relevant improvements coming for nextFetchPolicy in v3.2.0.

[hwillson]

This should no longer be an issue in @apollo/client@latest - let us know otherwise, thanks!

[forrestwilkins]

@hwillson I am still seeing this behavior even with @apollo/client@latest.

Update: I was able to resolve my issue by setting both nextFetchPolicy: "cache-only" and returnPartialData: true, which I discovered here: #6702