You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue
If a mutation is performed with the fetch policy cacheOnly before it is performed with cacheFirst or cacheAndNetwork, it will fail with a CacheMissException.
To reproduce
Run this minimal working example, tap the mutate button and check the queryResult printed to console:
Note that this example uses graphql_flutter: ^4.0.0-beta.1, as a comment on issue #597 recommended, but I experienced this also with 3.1.0.
Might be related to #779 also?
Expected behaviour
I was expecting the mutation to be cached without an exception, and with potential to be synced with network database in future.
Devices
Android and web.
Further details and context
In my example, if the hardcoded mutation in MutateWidget is first performed with the fetch policy cacheOnly, it will fail with a CacheMissException.
If it is first performed with cacheFirst or cacheAndNetwork, changing the fetch policy to cacheOnly, hot reloading and submitting the exact same mutation succeeds. If the mutation is not the exact same, e.g. if, in this example, "content": "I am content." is changed by one character to "content": "I am content!", a CacheMissException occurs.
This seems problematic because saving mutations to cache via cacheOnly when the mutation variables are dependent on user input will therefore rarely (only in the case of duplicate data entries) succeed.
At the moment, I care about this because I want user input to be saved to cache as it is entered, so it persists if app crashes or is closed, and only synced with an online database when the user chooses, with the goal of reducing unwanted/superfluous network requests.
Noob questions (feel free to ignore):
I'm new to GraphQL, databases, and even app development, so if I seem to be missing a concept, I probably am (and would be grateful to be told what it is)!
I think I've gathered that CacheMissExceptions occur when a query requests information that is not compatible 'structurally' with any of the information that exists in the cache, e.g. when querying the cache prior to ever querying the network database, or requesting e.g. 'title' and 'user' from cache when only 'title' has ever been requested from network.
It makes sense to me why these queries return exceptions when cacheOnly, as sufficient information to complete them is not available in cache. I don't understand why attempting to perform a creation mutation with cacheOnly results in this exception, though, as all?* information about the object to be added is being provided to the cache by the app.
*Is it something to do with having no access to the GraphQL schema and thereby no ability to determine if the shape of the mutation is valid, all required fields are provided etc?
The text was updated successfully, but these errors were encountered:
So, fundamentally what you're looking for here is an Offline Mutation Queue (#201). While the dream of offline-first design, we don't currently supply the ability to maintain that kind of long-term optimistic client state / eventual synchronization.
In your example, there is no way for us to know what the effect of createTodo should be on the cache
Really, more context should be added. Maybe we should disallow the option entirely, and say something like "FetchPolicy.cacheOnly is an invalid FetchPolicy for mutations. If you are trying to update cache data, you may be looking for client.writeQuery. If you are trying to get the previous mutation result, you may be looking for client.readQuery"
Feel free to come by the discord#support with questions also – prob could have saved you a fair amount of hair pulling 😅
micimize
changed the title
CacheMissException when mutating with cacheOnly fetch policy in 3.1.0 and 4.0.0
Unclear error when attempting to mutate with FetchPolicy.cacheOnly
Jan 24, 2021
Issue
If a mutation is performed with the fetch policy cacheOnly before it is performed with cacheFirst or cacheAndNetwork, it will fail with a CacheMissException.
To reproduce
Run this minimal working example, tap the mutate button and check the queryResult printed to console:
Note that this example uses graphql_flutter: ^4.0.0-beta.1, as a comment on issue #597 recommended, but I experienced this also with 3.1.0.
Might be related to #779 also?
Expected behaviour
I was expecting the mutation to be cached without an exception, and with potential to be synced with network database in future.
Devices
Android and web.
Further details and context
In my example, if the hardcoded mutation in MutateWidget is first performed with the fetch policy cacheOnly, it will fail with a CacheMissException.
If it is first performed with cacheFirst or cacheAndNetwork, changing the fetch policy to cacheOnly, hot reloading and submitting the exact same mutation succeeds. If the mutation is not the exact same, e.g. if, in this example,
"content": "I am content."
is changed by one character to "content": "I am content!"
, a CacheMissException occurs.This seems problematic because saving mutations to cache via cacheOnly when the mutation variables are dependent on user input will therefore rarely (only in the case of duplicate data entries) succeed.
At the moment, I care about this because I want user input to be saved to cache as it is entered, so it persists if app crashes or is closed, and only synced with an online database when the user chooses, with the goal of reducing unwanted/superfluous network requests.
Noob questions (feel free to ignore):
I'm new to GraphQL, databases, and even app development, so if I seem to be missing a concept, I probably am (and would be grateful to be told what it is)!
I think I've gathered that CacheMissExceptions occur when a query requests information that is not compatible 'structurally' with any of the information that exists in the cache, e.g. when querying the cache prior to ever querying the network database, or requesting e.g. 'title' and 'user' from cache when only 'title' has ever been requested from network.
It makes sense to me why these queries return exceptions when cacheOnly, as sufficient information to complete them is not available in cache. I don't understand why attempting to perform a creation mutation with cacheOnly results in this exception, though, as all?* information about the object to be added is being provided to the cache by the app.
*Is it something to do with having no access to the GraphQL schema and thereby no ability to determine if the shape of the mutation is valid, all required fields are provided etc?
The text was updated successfully, but these errors were encountered: