apollographql / apollo-client

:rocket:  A fully-featured, production ready caching GraphQL client for every UI framework and GraphQL server.
https://apollographql.com/client
MIT License
19.34k stars 2.65k forks source link

Stale data on variables change with no-cache fetch policy #6905

Open delyanr opened 4 years ago

delyanr commented 4 years ago

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 commented 3 years ago

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

sdankel commented 3 years ago

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 commented 3 years ago

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

sdankel commented 3 years ago

Yes, it repros in 3.3.19.

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

hwillson commented 3 years ago

Most (if not all?) of our stale data issues started waaaaaay back, when we decided to merge https://github.com/apollographql/react-apollo/pull/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 commented 3 years ago

Still reproducible with @apollo/client@3.4.12 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 commented 2 years ago

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 commented 2 years ago

9135 seems related 👀

paulmelnikow commented 2 years ago

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 commented 2 years ago

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 https://github.com/apollographql/apollo-client/issues/9135#issuecomment-988846529

phryneas commented 9 months ago

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.