Sub-selection without object reference

[0x6e6562]

I'm trying the writeFragment API and I'm getting the following error that indicates I should file an issue:

Encountered a sub-selection on the query, but the store doesn't have an object reference. This should never happen during normal use unless you have custom code that is directly manipulating the store; please file an issue.

This is using 1.0.0-rc.2.

Intended outcome:

The updated client side cache should be available for reads in the same way that it is without attempting a write.

Actual outcome:

The non-updated client cache is readable but after issuing the write, the cache is no longer readable.

How to reproduce the issue:

First of all, the cache needs to get updated, e.g.:

client.writeFragment({
  id: '6247840904372038495',
  fragment: gql`
    fragment ev on liveEvents {
      state
      user
    }
  `,
  data: {
    state: 'TAKE_UP',
    user: {
      id: '6247840904372038496',
      name: 'Some name'
    }
  },
});

The call to writeFragment completes successfully and the UI is updated, albeit not correctly.

In order to debug the UI update bug, I tried to read the fragment I just previously wrote and this triggered the sub-selection error in the library:

const data = client.readFragment({
  id: '6247840904372038495',
  fragment: gql`
    fragment e on liveEvents {
      state
      user {
        id
        name
      }
    }
  `,
});

[helfer]

@0x6e6562 Thanks for reporting the issue! I'm noticing that you're using a different fragment for writing vs. reading. Is that intentional?

[0x6e6562]

Good point! I'll re-test this using the same fragment to see if the behavior is the same.

[0x6e6562]

Interestingly if rewrite the code to re-use a common fragment definition, the error goes away. In this variant I can read from the cache, update some nodes on the fragment and then re-read the updated cache state back without an error:

const fragment = gql`
  fragment ev on liveEvents {
    id
    src
    dst
    since
    state
    user {
      id
      name
    }
    group {
      id
      name
    }
  }
`;

const data = client.readFragment({
  id: '6247840904372038495',
  fragment: fragment,
});

client.writeFragment({
  id: '6247840904372038495',
  fragment: fragment,
  data: {
    ...data,
    state: 'TAKE_UP',
    user: {
      id: '6247840904372038496',
      name: 'Some name'
    }
  },
});

const cached = client.readFragment({
  id: '6247840904372038495',
  fragment: fragment,
});

This doesn't solve the issue I am seeing with my view component losing all of it's state after I invoke writeFragment but that might have something to do with the fact that I am only updating a single node from a collection. I'm not sure how this relationship works so potentially I have another bug in my app that is not related to this specific cache access.

[0x6e6562]

After a bit more debugging I've noticed that the props of the component wired with connect is undefined immediately after updating the cache. Is this related to the fact that connect hooks into the redux store and the the update to the Apollo cache is on a different layer somehow? Or should one pass in some special options to connect to make it aware that it will need to respond to the underlying cache updates?

[0x6e6562]

OK, so I've gotten to the bottom of this.

Because I've writing a sub node into the updated fragment with the __typename field, the query blows up (silently) when the redux subscription tries to query the latest data from the cache at this line in the QueryManager.:

"Error: Can't find field __typename on object (6247840904372038496) {id": "6247840904372038496","name": "Some name"} at readStoreResolver

This scenario is not reported back the call stack.

As a result, the undefined is returned back into the props on the subscribing component and hence renders an empty collection, even though the client side cache is populated and up to date.

The simple solution to this is to make sure that sub nodes have the appropriate __typename field populated when using writeFragment.

@helfer I think we should close this issue because it is effectively user error. I'd do that now, except I'm not sure whether the __typename thing is worthy of it's own issue.

[stubailo]

The fact that the error is not reported well is definitely not great! I think that's really what this issue is about.

[calebmer]

Yep. Now that we expose functionality that was previously never accessible we need better errors.

To summarize this issue, you can’t do this:

client.writeQuery({
  query: gql`
    { foo }
  `,
  data: {
    foo: { a: 1, b: 2, c: 3 },
  },
});

client.readQuery({
  query: gql`
    { foo { a b c } }
  `,
});

You need to write with the same query you are going to use for reading. So { foo } must become { foo { a b c } } in the writeQuery call or else Apollo Client will incorrectly write your foo value as a JSON scalar instead of as a GraphQL object.

[helfer]

This will no longer be a silent error thanks to #1638, so I'm closing this.