Offset-based pagination fetchMore updates loading state inconsistently

[colinlawrence]

Issue description

I have identified a bug in the Apollo Client behaviour when using offset-based pagination with fetchMore. When using fetchMore at the end of a list, the loading state updates to true but then never updates to false when the returned data is an empty array (before the data is merged into the cache). This issue seems to be related to defining the returned object with an array field and having a large number of items in the list.

Link to reproduction

https://codesandbox.io/p/devbox/nifty-lake-fvhdxm

Reproduction steps

1. Visit the link above.

2. Click the button Fetch more to simulate reaching the bottom of list.

3. Continue to click the button Fetch more until all of the data is fetched (4996 items).

4. Click the button Fetch more one more time to simulate the final request that returns an empty array.

5. Note that the loading state does not return to false.

Expected behaviour

The loading state should return to false when all of the data is fetched.

Actual behaviour

The loading state does not return to false. It seems that the merged pagination data is being passed to the cache but this is not triggering events downstream.

Additional notes

Updating the total item count to 4995 items and performing the reproduction steps does not result in the same behaviour as the loading state returns to false as expected.
Updating the item schema definition and removing the attributes array field does not result in the same behaviour as the loading state returns to false as expected.

[jerelmiller]

Hey @colinlawrence 👋

I am currently investigating this. I can reproduce locally, but its such an odd one since it only seems to break with 4996 items exactly. I'm able to see what is causing it (no cache broadcast occurs on the empty result, hence why loading stays true), but that is so specific to 4996 items. That cache broadcast happens in all other cases I've tested. I'll continue to investigate and see if I can uncover what makes 4996 length so special here. Thanks for reporting!

[jerelmiller]

@colinlawrence from what I can tell, its a result of hitting the internal cache limit on the inMemoryCache.executeSubSelectedArray cache (see the Memory Management doc for more details). I noticed this limit is hit when using the 4996 number in your reproduction, but not 4995, hence why 4995 "fixes" the issue. If I increase the cache limit on that memoization cache, it works as expected.

With the Apollo Client Devtools, you can see that it is just shy of the limit when using 4995 items:

but 100% when using 4996 items, which is where you see the loading issue happen.

Unfortunately this is a tricky bug to solve as there are lots of moving parts at work here. For the time being, I'd recommend increasing the cache size limit on the inMemoryCache.executeSubSelectedArray cache until we fix this bug. You'll need to set that value before the Apollo Client code is loaded. I did this by creating a separate file that gets loaded before anything else:

// cacheSizes.ts
globalThis[Symbol.for("apollo.cacheSize")] = {
  "inMemoryCache.executeSubSelectedArray": 50000
};

// index.jsx
import './cacheSizes';