apollo-client: Unexpected Behavior with `fetchPolicy` "network-only" and `nextFetchPolicy` "cache-first" In 3.7.x

I’m in the middle of doing an upgrade of AC 3.6.8 to 3.7.x (currently tested and template made with 3.7.1) and I found something that I think is a bug, but I’m not sure.

Intended outcome: I have useQuery inside a component that is conditionally shown that uses the fetchPolicy of "network-only" and nextFetchPolicy of "cache-first". In the demo below, I’ve made the querying component conditionally mount with a toggle button. I expect that every time the component is mounted fresh, it should always fetch from the network and ignore the cache for that first load.

Actual outcome: It appears that, instead, the component comes to life, fetches from the network, fills the cache, then when I hide and fully unmount the component, then when I toggle it back to mounted, it does in fact start fetching from the network but seems to “apply” the "cache-first" policy too quickly and displays the cached data before the data comes back from the network. In the demo below, I’ve raised the delay on the network to 1.5s so it’s more obvious and made the length of the people array a count of the number of times the server data is used.

In other words, I think I expect:

click to show the querying component, I see Loading... for 1.5s, then 1 as the count.
click to hide the querying component
click to show the querying component, I see Loading... for 1.5s, then 2 as the count.

but instead, what actually happens on that last bullet is I never see Loading..., I see 1 as the count, then 1.5s later it updates to 2.

How to reproduce the issue: https://github.com/dairyisscary/react-apollo-error-template

Versions 3.7.x

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 4
Comments: 19 (14 by maintainers)

Commits related to this issue

Add a test to verify fix to #10222 works with a function to nextFetchPolicy — committed to apollographql/apollo-client by jerelmiller 2 years ago

Most upvoted comments

@JWo1F I am not quite content with the PR yet, and have most of my work directed elsewhere at the moment. I hope that I can return to this within the next few weeks, I’m sorry for the delay!

phryneas on Apr 21, 2023

@JWo1F I’ve made a PR release for you - you can install it with npm i @apollo/client@0.0.0-pr-10631-20230531131910

phryneas on May 31, 2023

I’ve picked this up and given it a shot over in #10631

phryneas on Mar 8, 2023

Hi All 👋

We are also experiencing this issue it seems. We were able to reproduce this both in a test case and in browser here: https://github.com/skrivle/apollo-next-fetch

This is a regular CRA project. You can run npm test and you’ll see the test failing. To make the test pass you can comment out the nextFetchPolicy config item in App.tsx

For the in browser reproduction please follow these steps:

npm start
click contact 1
click contact 2
click unload (which will unmount the app component)
click contact 1
observe that “loading” is shown very briefly and then it incorrectly shows the cached data for contact 2 until data for contact 1 is loaded.

Note: the conversation items have the same id but different content across the two requests. This is to illustrate the scenario where the properties of an object with a consistent id change over time.

skrivle on Dec 20, 2022

Fixed by #10631 and released with v3.7.17.

jerelmiller on Jul 6, 2023

@JWo1F I’ve picked this up again - the PR is in a ready-for-review state now and in a moment, there will be another build available to you over there in a comment 😃

phryneas on Jun 14, 2023

@JWo1F I’m very sorry that it has been yet another 3 weeks - we have been working hard to get the Next.js support package and the 3.8 beta out, so this has been a bit on the back burner.

I will be on conference for a week now, but already have a reminder set for this issue once I’m back. I’m really sorry that I can’t give you better news than that, but I thought I’d at least keep you in the loop.

Would it help you if I rebase the current PR onto the current main branch and make a PR-release that you can use in the meantime?

phryneas on May 30, 2023

Hey @JWo1F 👋 !

That is was I concluded as well. The bug was introduced in 3.6.9 (see my links in that comment for more references to the underlying issue). I have a failing test that demonstrates this issue. In fact I attempted to fix it but so far have been unsuccessful. I’m hoping to come back to this bug sometime soon to get a proper solution in place (if you’re curious about more specifics, see my comment on the challenges I’ve faced thus far).

jerelmiller on Jan 26, 2023

@jerelmiller Exactly. I’ll try to assemble an example highlighting the issue latest next week.

levrik on Nov 18, 2022