Data is undefined when loaded from cache

[exapsy]

I know this issue has been talked over and over again, since the old archived repository react-apollo.

But I don't really understand why there hasn't been a proper solution. I mean, we all kinda expected when there's a cache hit, data to represent that cache hit's data. So, why the implementation does not support that?

Unless, there's a detail that I missed and I'm clearly being ignorant in regards to the issue. Although, reading tons of those issues, did not really give me any clarification over why this keeps happening. :P So, I thought making a separate issue just to have a thorough explanation and see if I'm missing something was a good reason to make one.

Why when you load from cache and there's a hit, the cache's result is not returned to data like it would with network-only result? Instead, loading is false, but data is also undefined. Why is that the intended behavior? Who does that help and what use cases does it represent? And if its such a common problem that it has been discussed for years, maybe we could make a documentation for the case, but we would have to understand the reasons why it is not implemented in a more comfortable way then.

To sum it up:
Why when there's a cache hit, it doesn't just return the hit in the data return variable?

Intended outcome:

loading = true
data = undefined

// Cache hit!
loading = false
data = { ... }

Actual outcome:

loading = true
data = undefined

// Cache hit!
loading = false
data = undefined // Data was found, but data was not returned from cache

How to reproduce the issue:

const { data, loading } = useQuery(
	QUERY,
	{
		// If 'network-only' is used, it returns data correctly
		fetchPolicy: 'cache-and-network', 
	},
)

Versions
npx: installed 1 in 0.807s

System:
OS: Linux 5.7 Manjaro Linux
Binaries:
Node: 12.16.3 - ~/.nvm/versions/node/v12.16.3/bin/node
Yarn: 1.22.4 - ~/.nvm/versions/node/v12.16.3/bin/yarn
npm: 6.14.4 - ~/.nvm/versions/node/v12.16.3/bin/npm
Browsers:
Firefox: 81.0
npmPackages:
@apollo/client: ^3.1.1 => 3.1.1
apollo-link-context: ^1.0.20 => 1.0.20
apollo-link-http: ^1.5.17 => 1.5.17

[jdalegonzalez]

@exapsy This is probably too late to help you but...

Whenever this happens to me, it's always because a query that doesn't request a field populates the cache and a later query asks for another field and it's missing. The apollo client very unhelpfully drops the error on the ground even though it knows what field is missing. The gross way to figure it out is to put a breakpoint in @apollo/client/core/ObservableQuery.js around line 85 (search for diff = this.queryInfo.getDiff). You will see the return of void 0 - meaning no data for you. The diff, though, knows which fields are missing and could spit them out as console.warn - it just doesn't. Open up the diff in the watch window and you're set.

OR... less gross... set "returnPartialData" on your query options. Dump the output to console and compare what comes back with what you queried for. The missing fields will be the ones that are the problem. Another query will have hit the same object without asking for some of the fields.

[exapsy]

@jdalegonzalez If I recall correctly that's the way I solved it. Your answer helped me realize why that probably happens (although haven't tested it yet I must confess), so thanks!

If I remember I made this post mostly to raise awareness over the issue and solve it from apollo's side. As it's an issue that at developers may spend hours thinking its their fault when it's just a weird apollo' behavior. At least thats what happened with me, I actually spent days trying to debug this. Turning out as an apollo's issue, did roll some eyes. :P

It's seriously very weird knowing that the value exists in cache yet seeing that the value is not returned via useQuery without a single error/output that indicates there's something wrong.

[oeed]

I'd like also like to vouch that this needs a proper error message and description about what's going on.

I already have a wrapper hook that catches this and alerts me, but even with that I just spend half a day figuring out what was actually causing the merge issue – had to slowly disable various components and parts of queries until I stumbled upon it.

Just a simple console.warn saying 'this object couldn't be merged because field X... etc' would save many hours of headaches.

[jdalegonzalez]

If the apollo team is open to a PR that just adds this warning, I'll put it up. We wrote a patch for it for our own use.

[bignimbus]

Thanks all for your patience, this one slipped through the cracks a bit. @jdalegonzalez thanks for volunteering to open a PR. We would definitely be open to it but I think #8262 may have addressed this. I'll close this issue for now to keep things tidy but please feel free to @-me if that's incorrect and I'll re-open it!