Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
QueryResult.fetchMore() triggers unexpected refetch of indirectly related "cache-and-network" queries
See original GitHub issueIntended outcome:
When I call query.fetchMore() I expect this to never affect other queries or cause the other queries to be refetched.
Actual outcome:
When I call query.fetchMore() it sometimes causes a refetch of some “cache-and-network” query on the page.
It seems to happen when both queries (the one for which we call query.fetchMore() and the one that uses fetchPolicy: "cache-and-network") request data inside a common object type (e.g. __typename: "User").
How to reproduce the issue:
- Create or find an AC app where
query.fetchMore()is used on a query that shares data with other queries shown on-screen - Change the
fetchPolicyfor the other queries to “cache-and-network” - Start the app, open it, open the network tab in Chrome devtools
- Trigger the
query.fetchMore()in the app - Observe that the other queries (which were set to “cache-and-network”) are refetched after first (expected) request
Versions @apollo/client v3.3.13
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (1 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
This does sound like the same issue as #6916—see my thoughts in https://github.com/apollographql/apollo-client/issues/6916#issuecomment-901466918.
The central idea is that complete cache results (broadcast after a successful
fetchMore, for example) should be delivered immediately, by themselves, without triggering a network request for fetch policies likecache-and-networkornetwork-only. SettingnextFetchPolicy: "cache-first"is a good workaround in the meantime becausecache-firstsimilarly avoids the network given a complete cache result.I am actively working on that issue for v3.6. Unfortunately there are a number of test differences to work through, and those disruptions (even if they’re ultimately improvements, like fewer network requests) needed more intensive beta testing than we thought we could get before v3.5 was released. I’m still hopeful it will be safe for a minor release (rather than AC4).
Closing this as a duplicate (please join the discussion in #6916), but happy to reopen if my planned changes don’t (seem like they will) solve the whole problem here as well.
Maybe related to #6916