apollo-client: Using pagination with fetchMore and fetchPolicy involving network together causes bug where next page data is cleared

Intended outcome: fetchMore and updateQuery for pagination via useQuery should work well without a bug with fetchPolicy that involves network such as 'network-only', 'cache-and-network', etc.

Actual outcome: fetchMore and updateQuery works, but updateQuery immediately triggers apollo’s query observables to refetch query with old variables (with pagination cursor = null). Refetched data (where cursor = null) overwrites result from updateQuery causing new page data to be appended and then immediately removed because of the overwrite. This clearly seems like a bug of apollo client.

How to reproduce the issue: Implement useQuery pagination with cursor and updateQuery from official example and use fetchPolicy: "cache-and-network" or "network-only".

Versions System: OS: macOS 10.15.3 Binaries: Node: 13.13.0 - /usr/local/bin/node Yarn: 1.22.4 - /usr/local/bin/yarn npm: 6.14.4 - /usr/local/bin/npm Browsers: Chrome: 81.0.4044.138 Firefox: 75.0 Safari: 13.0.5 npmPackages: @apollo/client: ^3.0.0-beta.49 => 3.0.0-beta.49 @apollo/link-context: ^2.0.0-beta.3 => 2.0.0-beta.3 @apollo/link-error: ^2.0.0-beta.3 => 2.0.0-beta.3 @apollo/link-persisted-queries: ^1.0.0-beta.0 => 1.0.0-beta.0

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 16
  • Comments: 21 (5 by maintainers)

Most upvoted comments

Maybe a good idea to actually add nextFetchPolicy into the docs next time instead of everyone spending hours working out why the initial query just fired again…like I just did. Also how many breaking changes can you possible introduce in a new version? Migration is basically just changing the entire application zzzzzzzz.

@benjamn Yes, that is the case. And I use as fetchPolicy ‘cache-and-network’. version 3.1.2

I currently circumvent this behaviour of the data of the original query being refetched, by using the current option values: { fetchPolicy: ‘cache-and-network’, nextFetchPolicy: ‘cache-first’, }

by using nextFetchPolicy ‘cache-first’ it wil not refetch the original query after calling fetchmore. But I hope that for the next releases this should not be necessary.

In my case, nextFetchPolicy is not working for @apollo/client: ^3.3.19, and am still getting old data on fetchmore

    QUERY,
    {
      variables: queryVariables,
      // notifyOnNetworkStatusChange: true,
      // fetchPolicy: "network-only",
      networkStatus: networkStatusIndex,
      notifyOnNetworkStatusChange: true, 
      fetchPolicy: 'cache-and-network',
      nextFetchPolicy: 'cache-first',
    }
  );```

After searching for hours, finally I found this temporary solution. And for the sake of other readers like me, when using nextFetchPolicy: “cache-first” doesn’t trigger loading state. Just in case you need to track loading state, you have to set ‘notifyOnNetworkStatusChange’ to true.

I have this issue on 3.1.1

@arminbro That’s true. Looks like there’s one issue tracking this already https://github.com/apollographql/apollo-client/issues/6354

@benjamn this issue can be reopened in 3.1.1. After a fetchMore, the data is refetched.

This does seem to be fixed in the latest RCs, as confirmed by @yamalight’s reproduction (https://github.com/apollographql/apollo-client/issues/6327#issuecomment-633526732).

The loading status problem for fetchMore (#6354) is a known bug that we still need to fix. Feel free to leave comments over there if you have any insights/reproductions to add!

@arminbro Looks like this is fixed in @apollo/client@3.0.0-beta.53

It looks like this issue/bug is introduced in version 3.0.0-beta.46

Having the same issue. Here’s the simplest repro on codesandbox