-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Regression] apollo-client 3.0.0-beta.44 does not rollback optimistic updates #6183
Comments
I suspect that re-accessing the same query with another |
Yeah I think this is a duplicate of #5790 |
I gave this another try with @beta.48 (#6221), but unfortunately it still doesn't roll it back. Worth mentioning, I also noticed another bad behaviour on the Apollo side: if I use |
We're looking into this and tracking progress in #5790, so I'll close it here. Thanks! |
This fixes an issue found by @darkbasic while working with optimistic updates: #6183 (comment) The cache-first FetchPolicy is important not just because it's the default policy, but also because both cache-and-network and network-only turn into cache-first after the first network request (#6353). Once the cache-first policy is in effect for a query, any changes to the cache that cause the query to begin reading incomplete data will generally trigger a network request. However, if the source of the changes is an optimistic update for a mutation, it seems reasonable to avoid the network request during the mutation, since there's a good chance the incompleteness of the optimistic data is only temporary, and the client might read a complete result after the optimistic update is rolled back, removing the need to do a network request. Of course, if the non-optimistic read following the rollback is incomplete, a network request will be triggered, so skipping the network request during optimistic updates does not mean ignoring legitimate incompleteness forever. Note: we already avoid sending network requests for queries that are currently in flight, but in this case it's the mutation that's in flight, so this commit introduces a way to prevent other affected queries (which are not currently in flight, themselves) from hitting the network.
This fixes an issue found by @darkbasic while working with optimistic updates: #6183 (comment) The cache-first FetchPolicy is important not just because it's the default policy, but also because both cache-and-network and network-only turn into cache-first after the first network request (#6353). Once the cache-first policy is in effect for a query, any changes to the cache that cause the query to begin reading incomplete data will generally trigger a network request, thanks to (#6221). However, if the source of the changes is an optimistic update for a mutation, it seems reasonable to avoid the network request during the mutation, since there's a good chance the incompleteness of the optimistic data is only temporary, and the client might read a complete result after the optimistic update is rolled back, removing the need to do a network request. Of course, if the non-optimistic read following the rollback is incomplete, a network request will be triggered, so skipping the network request during optimistic updates does not mean ignoring legitimate incompleteness forever. Note: we already avoid sending network requests for queries that are currently in flight, but in this case it's the mutation that's in flight, so this commit introduces a way to prevent other affected queries (which are not currently in flight, themselves) from hitting the network.
This is the repro: https://github.com/darkbasic/gh6183
After cloning use
yarn && yarn start
to run it. There is a button next to each article: if you delete the first two of them everything will work out as expected, but as soon as you will delete the third one the server will return an hardcoded error after a 3 seconds delay and apollo-client won't rollback the optimistic update.If you run
git revert HEAD && yarn install:clean && yarn start
you will downgrade to apollo-client 2.6 and you will find that everything will work as expected: after 3 seconds apollo-client will rollback the failed mutation.Versions
The text was updated successfully, but these errors were encountered: