Intended outcome:
When I use useQuery with fetchPolicy: 'cache-and-network' for loading data from the server I want return data only one time.
In version 3.0.0 it works correctly like this:

Actual outcome:
When I use useQuery with fetchPolicy: 'cache-and-network' for loading data from the server it is doing infinity loop like this:

If I remove fetchPolicy: 'cache-and-network' it works correctly
How to reproduce the issue:
I think it is something wrong after version 3.0.0, because in version 3.0.0 it works correctly
Versions
"@apollo/client": "3.1.3",
I believe https://github.com/apollographql/apollo-client/issues/6760#issuecomment-668188727 explains what's happening here. Can you try nextFetchPolicy: "cache-first"?
@benjamn Thank you, for your fast answer. It works
I'm having the same issue and while nextFetchPolicy will probably work, I am curious what's causing it. Is it some other query that's getting (part of) the same field which causes the query to run again? If so is there way for me to see what other query is causing this?
Also if the old behavior was basically to have nextFetchPolicy to cache-first as default, won't it make sense to have it as default now? Getting a bug like this in production would overload our servers very fast (we don't have a loader to show it's refreshing so it's not even as obvious it's happening)
@JesseZomer Yes, some other query (or direct cache modification) is updating a field in the cache that was previously consumed by the query that's getting rerun. This chain of events is something we hope to make clearer through the Apollo devtools, but for now you might try setting breakpoints here (to see how each fetch policy is getting applied) or here (to see where the cache notifications are coming from, which follows synchronously from any cache update, so you can usually look up the call stack to find out what the modification was).
It's important that cache-and-network and network-only do what they say, even if that's often not exactly what people want. We considered adding new fetch policies, but settled on nextFetchPolicy as a flexible way to achieve a wide variety of hybrid fetch behaviors. For example, you might want to switch back to cache-only to avoid ever making another network request, while still listening for relevant cache updates. Instead of introducing 4+ new fetch policy combinations, nextFetchPolicy easily unlocks all the possibilities that we've encountered.
@benjamn I get the decision 馃憤
So we have a overview page and a detail page. It looks like the detail page is requesting more fields (obviously) of the same object. and this makes it go in an infinite loop.
I'm having a bit of trouble of coming up with a good use-case doing a network request for when something else updates the cache. Isn't the point of updating the cache so that it has the latest state?
Most helpful comment
@benjamn Thank you, for your fast answer. It works