mutations through watchQuery use cacheAndNetwork, which yields unexpected results

[micimize]

the default fetch policy for client.mutate is networkOnly, because it is usually the case that the fields requested correspond to mutated data, and thus are expected to be stale if fetched eagerly from the cache.

However, when a mutation is made with client.watchQuery (such as with the Mutation widget), the cacheAndNetwork policy is used by default, resulting in unexpectedly stale data when an optimisticResult is not provided.

Another serious issue is that the same mutation, with the same variables, might return different entities. If those results are used in parts of the application, the results of the latest usage will overwrite those of the older ones.

[micimize]

To illustrate the issues further:

Mutation results are cached (more or less) under mutationName(data: ${jsonEncode(variables)}), so when an order is created with the same parameters, the previous result will be grabbed from the cache eagerly.

Lets say we have a mutation,

mutate createOrder($placeId: ID!){
  createOrder(placeId: $placeId) { ...orderFields }
}

It is called once, then that order is mutated later, but the results of the mutation are still used in the UI as a list item. That mutation sits in the cache like so:

{
  "Mutation": {
    "__typename": "Mutation",
    "createOrder({\"data\":{\"placeId\":\"bar-3-aaaa-aaaa-aaaa-aaaaaaaaaaaa\"}})": {
      "$ref": "Order:old-closed-order-bbbb-bbbb-bbbb-bbbbbbbbbbbb"
    }
  }
}

If a new mutation is made to create a fresh order:

• It's eager result will be the old order
• the new order will overwrite the old order reference in the cache
• any UI using the old order mutation results will be overwritten (incorrectly)

A potential workaround for now is to use a differentiating variable. Will have to think/investigate more.

[micimize]

This might require some significant refactoring. In apollo, useMutation calls client.mutate, which then calls markMutationOptimistic in the QueryManager, which just passes the update callback all the way down to a block within recordOptimisticTransaction. This is very different from what we do, which is to just reuse watchQuery for Mutation.

The quickest way for us to solve this IMO is to add a client.watchMutation with a new default fetch policy FetchPolicy.writeCacheFromNetwork that writes to the cache but does not re-read from the cache, and thus also does not rebroadcast (i.e. isRebroadcastSafe is always false). This would also be a good time to add rebroadcasting to the docs on FetchPolicy. This is not an ideal solution, but it is quick to implement. It also allows for the use case of "incidental post-mutation querying" which users might be making use of without noticing.

[micimize]

Maybe add other general constraints and errors around the mutation code path, as it allows for other jank like #792 (comment)

[micimize]

Closing this with #795 and leaving the more substantial redesign to #798

[HofmannZ]

🎉 This issue has been resolved in version 4.0.0-beta.7 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[HofmannZ]

🎉 This issue has been resolved in version 4.0.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀