Stale data on variables change with no-cache fetch policy

[delyanr]

Branching off from #6039 so the issue doesn't get lost.

Intended outcome:

The data returned from useQuery should be undefined when the variables change even when using fetchPolicy: 'no-cache'.

Actual outcome:

The data remains stale regardless of #6566.

How to reproduce the issue:

I've tweaked the reproduction provided in #6039 - please click here.

Versions

I'm currently using v3.1.2 (see below) but the same issue happens in the latest 3.2.0-beta6.

  System:
    OS: Windows 10 10.0.19041
  Binaries:
    Node: 14.4.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.4 - C:\Program Files\nodejs\yarn.CMD
    npm: 6.14.5 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 84.0.4147.135
    Edge: Spartan (44.19041.423.0), Chromium (84.0.522.63)
  npmPackages:
    @apollo/client: 3.1.2 => 3.1.2
    apollo-link-rest: 0.8.0-beta.0 => 0.8.0-beta.0

[hwillson]

Let us know if this is still a concern with @apollo/client@latest - thanks!

[sdankel]

Is this confirmed fixed in any version? Can we reopen the issue until it's confirmed fixed? @hwillson @benjamn

We are having this issue in 3.0.0-beta.22 with no-cache fetchPolicy. This bug makes no-cache effectively unusable.

[brainkim]

@sdankel Can you try against 3.3.19? Sorry to hear you’re having trouble.

[sdankel]

Yes, it repros in 3.3.19.

Updated @delyanr 's repro with 3.3.19 and a working GraphQL endpoint here.

[hwillson]

Most (if not all?) of our stale data issues started waaaaaay back, when we decided to merge apollographql/react-apollo#1639. This has been a monstrous source of problems over the years, and is an area we definitely need to get right as we work on our React integration layer rewrite.

[pioneer32]

Still reproducible with @apollo/[email protected]
We keep fetchPolicy: 'no-cache', which mitigates the problem with queries that randomly return results for different set of variables.... but having no cache costs us a lot, as the client constantly hits the api+db etc....

Maintaining a patch with ds300/patch-package is not a desirable option for us. It'd be extremely amazing if this issue was fixed here in the first place.

Any chance fixing issue could be included into the road-map? TIA

[winghouchan]

I have a similar issue when using useLazyQuery, although I think it affects queries of all fetch policies, not just no-cache. Issue even occurs even across Apollo cache clears. Reproduction available here: https://k2eih.csb.app/. Press Query 1 then optionally Clear store then Query 2. The first log after pressing Query 2 will contain data returned in the first query and also a network status of ready.

[winghouchan]

#9135 seems related 👀

[paulmelnikow]

In case it's helpful to others: I was having this issue in 3.2.5, but upgrading to 3.5.6 fixed it.

[paulmelnikow]

In case it's helpful to others: I was having this issue in 3.2.5, but upgrading to 3.5.6 fixed it.

Oops, turns out it doesn't completely fix the problem. I get stale data for one render, then on the next render, loading flips to true and data changes to undefined. This happens regardless of the fetchPolicy. So, perhaps it is a different issue.

Added: Same issue as #9135 (comment)

[phryneas]

I believe this is a misunderstanding of no-cache: no-cache means that no data will be written or read from the InMemoryCache that is shared between all hooks and components.

It does not mean that the hook itself will not preserve previous data if you change query variables.

To my knowledge, we don't have a feature like that. You'd have to treat the result as undefined as long as the query is loading yourself.