using possibleTypes in the cache subsequently requires every test mock to set a __typename

[xxx]

Intended outcome:
I don't get invariant violation errors for every mock that doesn't explicitly include a __typename field.

Actual outcome:
Every test that uses a mock without __typename fails with an invariant violation. This causes hundreds of failures in our test suite. Changing the addTypename prop on MockedProvider has no effect on this behavior.

How to reproduce the issue:
Add a possibleTypes field to your cache, then run a test that uses a mock that doesn't have __typename set in every object.

It looks like this is intended. From writeToStore.js:

                else if (policies.usingPossibleTypes &&
                    !hasDirectives(["defer", "client"], selection)) {
                    throw process.env.NODE_ENV === "production" ? new InvariantError(8) : new InvariantError("Missing field '" + resultFieldKey + "' in " + JSON.stringify(result, null, 2).substring(0, 100));
                }

It's not clear to me why these behaviors are intertwined like this though. I'd rather not have to wade through all of these failed specs just for __typename, when without the possibleTypes setting (which only configures a single type out of dozens), things are fine.

Versions

System:
OS: Linux 5.3 Ubuntu 19.10 (Eoan Ermine)
Binaries:
Node: 12.16.3 - ~/.nvm/versions/node/v12.16.3/bin/node
Yarn: 1.22.4 - ~/.yarn/bin/yarn
npm: 6.14.4 - ~/.nvm/versions/node/v12.16.3/bin/npm
Browsers:
Chrome: 83.0.4103.116
Firefox: 78.0.2
npmPackages:
@apollo/client: 3.1.4 => 3.1.4

Edit: 3.1.5 has the same issue.

[xxx]

Here's one error that's completely wrong:

Invariant Violation: Missing field '__typename' in {
  "collection": [
    {
      "id": "1",
      "name": "project 1",
      "type": "project",

here's the full mock in question. It clearly has a __typename:

  {
    id: '1',
    name: 'project 1',
    type: 'project',
     __typename: 'BaseProject'
  }

[benjamn]

@xxx This exception (which used to be a warning) was an intentional breaking change introduced by #6055 in Apollo Client 3.

Although I get that it's annoying to see so many test failures, your mock data really does need to have the appropriate __typename fields in all selection sets. Since so much of what the cache does depends on __typename information (normalization, type and field policies, fragment matching, and more), mock data that's missing __typename fields is likely to behave differently from real data, in hard-to-predict ways. That's why the cache automatically adds __typename fields unless you disable that behavior (which is safe because any spec-compliant GraphQL server will be able to provide the __typename for any object you request).

In your comment #7001 (comment) above, it looks like the object that contains the collection key is the one that's missing a __typename field, whereas the BaseProject object is just one of the elements of the collection array. Unless I'm misreading things, the error is not wrong in this case.

[hwillson]

It doesn't sound like there is an outstanding issue here, so closing. Thanks!