@jgan42 @CaptainStiggz You may want to switch back to fetchPolicy: "cache-first" after the initial request, since network-only will always go to the network, hence the extra network requests. To to that, use nextFetchPolicy:

[rossm6]

@jgan42 @CaptainStiggz You may want to switch back to fetchPolicy: "cache-first" after the initial request, since network-only will always go to the network, hence the extra network requests. To to that, use nextFetchPolicy:

const { loading, data, fetchMore } = useQuery(ALL_PEOPLE, {
  variables: { skip: 0 },
  fetchPolicy: 'network-only',
  nextFetchPolicy: 'cache-first',
});

Originally posted by @benjamn in #7307 (comment)

I've used this throughout my product which is close to completion. I've realised now though that if a subsequent query fails then it uses the cache result.

In short how does one use apollo js to execute queries without ever involving the cache? Live data components must be one of the most common use cases of a graphql client surely. I'm a little surprised at how difficult this seems to be to achieve in apollo. Would be delighted to be told I've not understand something though and it is in fact easy.

***UPDATE ***

I've tried "no-cache" for both policies and it causes two network queries where the second is a duplicate of the very first query. So I'm stuck.

Is client.query the better way forward may be?

[rossm6]

Hi

I've been trying to replicate this issue. Please see the following - https://github.com/rossm6/react-apollo-error-template

It demonstrates that "no-cache" for each fetch policy produces a duplicate query. In this reproduction the duplicate appears to be a duplicate of the last query. I don't know why but in my product the duplicate query - the unwanted follow up query - appears to use the original variables that the very first fetch used. So quite similar.

Hopefully this helps.

Put simply I need a single query which just uses the latest variables and doesn't involve the cache.

** TO BE CLEAR **

There are two issues I think. One is that errors which are returned appear to make apollo js go back to the cache for the data. The second issue concerns an unwanted duplicate query which seems to happen with many different fetch policies. This is what my reproduction concerns.

[benjamn]

@rossm6 Glad to hear you're in the home stretch with your product, and happy to help address any remaining difficulties! These problems are probably not unique to you, after all.

This issue seems related to the goals of #8465, available in prerelease since @apollo/[email protected]. In the same way the fetchPolicy is reset when variables change, I believe you're right to suggest the fetchPolicy should be reset after an error occurs.

PR #8465 also allows nextFetchPolicy to remain in the options after it's been used, so it would presumably apply again, any time an error (or variables change) resets the fetch policy to network-only temporarily, resulting in cache-first again for future requests.

Does that sound like what you were expecting/hoping should happen?

[rossm6]

Hi

Sorry please can you clarify what you mean by "the fetchPolicy is reset when the variables changes"?

I thought that "fetchPolicy" always meant the "first" fetch so this would be the fetch Initial if using the lazy query hook and the first fetch if using useQuery. All other fetches I assumed were governed by the "nextFetchPolicy", right?

Your comment has left me wondering if the policy reverts if the variables have changed?

[jerelmiller]

Hey @rossm6 👋

This issue is quite stale at this point and its unclear if this is still an issue. I'm going to go ahead and close this, but please let us know if you are still experiencing an issue and we'd be happy to help. Thanks!

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Client usage and allow us to serve you better.