proxy.readQuery throws an error on not executed queries

[lxwbr]

I am having a structure which looks like the following:

type Person {
  id: string
  friends: [Friend]
  addresses: [Address]
}

At one point in time I am fetching one persons addresses, which is being cached in the store while using the id field.

At a later point in time, I am doing a mutation on the object and add a new friend. Please note, that at this point in time the user did not request to fetch the list of friends for now. In order to keep the friends list up to date, I am still doing a proxy.readQuery operation on the query which is responsible for fetching all friends of a user and pushing the new friend into it. For now I don't keep track if the user already executed this query at some point in the past. If the user did so, everything is alright. If however he did not fetch the list of friends and I am trying to execute the proxy.readQuery on that query, I will get an exception like that:

Error: Can't find field PersonFriends on object (Person:UGVyc29uOjE=) {
  "id": "UGVyc29uOjE=",
  "Viewer_addresses": {
    "type": "id",
    "id": "$Person:UGVyc29uOjE=.Viewer_addresses",
    "generated": true
  },
  "__typename": "Person"
}

I would like to prevent catching this exception. Is there any way from Apollo's side to know if a certain query was executed in the past and don't execute the proxy.readQuery in that case?

[janaleible]

See also issue #2007

[lxwbr]

@janaleible did you manage to come up with a workaround on this issue?

I noticed that readFragment supposed to return either the FragmentType or null. This might be a solution for this issue, but I didn't try it out yet.

EDIT: according to the docs, this is the intended behaviour for .readFragment:

If a todo with that id does not exist in the cache you will get null back. If a todo of that id does exist in the cache, but that todo does not have the text field then an error will be thrown.

EDIT2: it would be nice to generally have some kind of executed flag on queries in the store. That would provide some additional flexibility e.g. while designing mutations, one could decide which payload is needed according to the data already fetched (for it to be refreshed from mutation result)

[janaleible]

Not exactly a workaround, unfortunately. I ended up avoiding the isssue altogether by using a network-only fetchPolicy for this particular query.

[stale]

This issue has been automatically marked as stale becuase it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions to Apollo Client!

[lxwbr]

This issue is not solved, no need for closing.

[jbaxleyiii]

@Zunder do you have a reproduction app for this? I'd be happy to take a look!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions to Apollo Client!

[stale]

This issue has been automatically closed because it has not had recent activity after being marked as stale. If you belive this issue is still a problem or should be reopened, please reopen it! Thank you for your contributions to Apollo Client!