Concurrently requesting a node w/ and w/o an identity triggers #380

[nevir]

This seems like it might be somewhat different than #380 - so reporting as a separate issue:

In our application, we have configured ROOT_QUERY.viewer to be the current user. As seems common, many of our queries are rooted off of that node for convenience. In this instance, we made the following requests concurrently (but far enough apart that they are not merged):

{
  viewer {
    id
    name
    ...
    organization {
      posts { ... }
    }
  }
}

{
  viewer {
    organization {
      posts { ... }
    }
  }
}

Depending on which returns first, we can encounter the following error:

Can't find field id on object {"organization": "ROOT_QUERY.viewer.organization", "__typename": "User"}.
Perhaps you want to use the `returnPartialData` option?

If we run the queries in serial (requesting the viewer's id first) this does not occur. Subsequent queries that use viewer but do not reference its id field also go through.

[Poincare]

@nevir

I don't think this is related to #380 but it is closely related to #410 and #344.

Judging from the fact that the ids generated by Apollo don't have "$" in front of them, the application is still using a release that's older than one of the two released today. If so, could you update to the latest release and see if that fixes the issue? If not, I'll look into it tomorrow and hopefully fix it.

[nevir]

Aha, awesome - I'll get our copy rebased and caught up today

[nevir]

Alright, caught up - the requests still fail (which is expected, right?), but I get a more reasonable error now:

the application attempted to write an object with no provided id but the store already contains an id of <id> for this object.

[Poincare]

Yup, that's what should happen. The way the store is structured, there isn't really a way out of this problem other than just asking for IDs as far as possible.

I guess we can now close this issue since it is exhibiting intended behavior.

[nevir]

👍