Infinite network requests with non-normalized objects about apollo-client HOT 3 OPEN

This sounds very similar to this issue, a fix was being worked on for that, but not sure what the status is for that and if it would fix this issue also.
I'm not sure what the difference is with this repro and mine, I didn't look in detail, but in my repro it only occurred with the read function defined, but it sounds like you're having the same issue even without a read function.

from apollo-client.

Hi @oscar60310 👋

Thanks for opening this issue with a clear reproduction of what you're seeing!

First, when I ran your reproduction, I noted that the fetchPolicy and nextFetchPolicy had no bearing on the infinite loop behavior, so I commented them out.

Before defining a merge function for it, I expected Apollo to log a warning and replace the value as described in the documentation.

This is indeed what's happening, but for reasons I'll get into below, our two queries are "replacing the value" in an infinite loop, with no way to resolve the feud. First, here's the warning I saw:

Can you confirm you see a similar warning?

The warning notes that Cache data may be lost when replacing the nested field of a Foobar object and that This could cause additional (usually avoidable) network requests to fetch data that were otherwise cached.

As you noted, when the Nested entity can't be normalized, its fields are nested on our cached Foobar:foobar entity.

The problem arises when QUERY_DATA_1 and QUERY_DATA_2 select non-overlapping fields on this non-normalized entity. In practice, this means that as soon as e.g. QUERY_DATA_1 resolves with foobar.nested.value1, QUERY_DATA_2 sees that foobar.nested.value2 is missing in the cache, kicking off a network request whose response removes value1 from the cache and replaces it with value2. QUERY_DATA_1 then "notices" value1 is missing, and the cycle repeats forever.

I think a note in the docs advising against selecting non-overlapping fields on non-normalized objects would be helpful but would love any other ideas/suggestions you have here. Thanks!

from apollo-client.

Hi @alessbell , thanks for the explanation!

Can you confirm you see a similar warning?

The warning notes that Cache data may be lost when replacing the nested field of a Foobar object and that This could cause additional (usually avoidable) network requests to fetch data that were otherwise cached.

Yes, I see the same warning. It makes me think that we might lose the benefit of the cache. In the worst case, each hook would send a single query. However, the consequence is much more critical than simply not using the cache; it could result in infinite requests being sent to our server.

Is it possible to escape from the loop when we detect a cache issue?

I noticed that if we don't have a value that changes with each request, there won't be an infinite loop, and the cache is not replaced (component1 and component2 both get the correct value).

export const QUERY_DATA_1 = gql`
  query foobar1 {
    foobar {
      id
      # lastOnlineAt
      nested {
        value1
      }
    }
  }
`;

from apollo-client.