Run final mutation update against non-optimistic data.

[benjamn]

Providing an optimisticResponse when performing a mutation is never mandatory, since optimistic updates are an optimization for perceived performance. By corollary, if you switch back and forth between providing an optimisticResponse and simply waiting for the mutation to finish, that choice should have no lasting impact on the final state of the cache. After the mutation finishes, you should not be able to tell that there was ever an optimisticResponse.

InMemoryCache maintains a system of layered EntityStore objects to represent optimistic updates, so it can easily throw individual layers away when a mutation finishes, ultimately leaving only the "realistic" data behind. However, in cases where two or more optimistic mutations are running at the same time, directly competing to update the same data, it is possible for the final update function call for one mutation to leak still-active optimistic data from the other mutation into the root layer of the cache. This leaking of optimistic data poses a subtle problem for the goals described above, because it means using an optimistic response can have lasting effects on non-optimistic cache data.

To address this problem, we need to make optimistic data invisible to the final (non-optimistic) invocation of the mutation update function, somehow. Because of the layering of the InMemoryCache, this turns out to be relatively straightforward, since the root layer is accessible in isolation from any optimistic data that might be layered on top of it.

Specifically, the final time we call the update function for the mutation, we do so within a cache transaction where cache.optimisticData is temporarily set to refer to the same root EntityStore object as cache.data, so a typical readQuery-transform-writeQuery update pattern cannot accidentally read from the optimistic data of other concurrent mutations. Note that we do not need to wait for all optimistic mutations to finish before running the final update function for an individual mutation, because we have the ability to hide optimistic data without removing it (yet).

This bug is relatively rare because it requires two or more optimistic mutations to be competing to update the same data at the same time, which is uncommon. However, the bug is reliably reproducible under such circumstances, and is now adequately regression-tested (see tests included in this PR).

[benjamn]

These tests were failing silently because of the way the tryFunctionOrLogError function was turning exceptions into console errors. In other words, eliminating tryFunctionOrLogError is important to ensure these tests will actually report future regressions in the way exceptions are handled for mutation update functions.

[benjamn]

Flagging this comment since it brings up a tricky issue that I investigated but decided not to change in this PR.

Replaying optimistic transactions involves running arbitrary user code, so doing it repeatedly (e.g. whenever the root layer changes) could have serious performance (and perhaps even logical) implications. I considered keeping track of which fields were read by the previous update function, so that the cache could skip replaying updates not affected by the latest changes, but I think that overcomplicates the problem, and leads to a situation where it's very hard to predict how many times your update function will run.

At the end of the day, any marginal benefits of repeatedly recomputing optimistic data are generally overshadowed by the benefits of just throwing the optimistic data away after the mutation finishes.

[hwillson]

Great solution @benjamn 👍 - thanks!