Ben Newman

I don't mean to minimize the discussion that has been happening here, but some of the common themes in `useLazyQuery` behavior that folks are describing seem to be working as...

There needs to be a `FetchPolicy` that gives you only the final network result, without an extra `loading: true` result, because delivering that extra result triggers a potentially unnecessary rerendering...

@joebernard If you're able to test with a beta release, it would be interesting to see if `@apollo/[email protected]` has the same issue? Is there anything unusual about these optimistic responses?...

@joebernard A separate ticket would be great! If the issue is reproducible and you have time, please include a [reproduction](https://github.com/apollographql/react-apollo-error-template), so we can figure out exactly what's up.

I would challenge your assumption that this kind of mistake should be "non-fatal." If an ID can't be computed for some instances of an object type, those deficient objects will...

Ok, I think we agree on all of that. We will dig into this and make sure that we're providing appropriate `observer.error` handlers for all of our `Observable`s, so that...

@vfonic If you don't know why you're upgrading ("zero new functionality" is absurd, though I assume you just mean you don't see value in any of the new functionality), any...

> One last thing and then I'll finish my blabering: a simple codemod could make this shuffling between v2 and v3 much easier. (apollo-client => @apollo/client, react-apollo => @apollo/client, graphql-tag...

A couple updates: * After #8678, this exception should no longer happen (ever) for `keyArgs`, since the function for handling `keyArgs` (`computeFieldKeyObject`) is now separate from the function for handling...

Thanks for following the release and taking the initiative to propose and implement this change! To be completely honest with you, the `NormalizedCache` interface methods (`get`, `set`, etc.) are still...