apollo-ios: Query watcher not being called when cache is updated on an element by another query/subscription/mutation
Bug report
Query watcher not being called when cache is updated on an element of a collection that is added after calling watch
Versions
Please fill in the versions you’re currently using:
apollo-ios
SDK version: 0.34.0- Xcode version: 12.0.1
- Swift version: 5.3
Steps to reproduce
I’ve been trying a lot of things on that one and wasn’t able to find a way to fix my problem. So in my app I’m having a list of conversations, so I’m creating a watch
on a query that returns the list of conversations, this is something like that:
user {
uuid
firstName
lastName
conversations {
uuid
unreadMessagesCount
}
}
In the app we use the
uuid
key to handle cache, so we make sure to always passuuid
in our queries to automatically handle cache update.
So the role of the watcher I’m talking about is both to update existing conversations and also be able to catch when a new conversation is created (it can happen and not be initiated by the user, we then trigger an event from the backend that is listen from a subscription in the app). When this event happens it returns something like that
event {
newConversation {
conversation {
uuid
unreadMessagesCount
// This is the part that adds the new conversation to the existing ones of the users in the cache
user {
uuid
conversations {
uuid
unreadMessagesCount
}
}
}
}
}
It works great, meaning that when this event happens, the watcher is being called with the newly created conversation, but the issue is that any new cache update for that specific conversation doesn’t trigger the watcher again.
After investigating a bit, I realised that the cache is being updated because if I’m adding 3 new messages into the new conversation (setting the unreadMessagesCount
to 3), the watcher doesn’t get called but then if I add 1 new message into an old one, the watcher is being called with both the new message on the old conversation and the 3 new on the new one.
So it really seems like watch
is not being called again for changes on an item that wasn’t in a collection when the watch
was initially made. I’ve also take a look at https://github.com/apollographql/apollo-ios/issues/281 and making a fetch
on the same query again after the event doesn’t fix the issue.
Let me know if I’m not clear on something as the whole thing is a bit complicated to explain.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 10
- Comments: 38 (20 by maintainers)
After investigation, the issue is more about the type of transport, aka
WebsocketTransport
rather than the type of operation. I’ve opened a PR with a solution.@designatednerd Do you have any updates on this issue?
@designatednerd
Taking the occasion to jump again on the conversation. Please let me know when you have news around the
WebSocketTransport
not publishing into the store bug, this is the last one preventing us from using the latest versions.Many thanks!
Planning on tackling this soon!
@Narayane I don’t have an example, but if you look at how the default network intercept provider is set up, you’ll see it’s fairly simple.
@ketenshi That’s a more complicated issue, unfortunately - we don’t presently have a recommended workaround but i’m working on some thoughts around it.
Thanks for the poke! Right now the main update is that we’ve had to roll back Starscream to an older version due to some crash issues a bunch of people were experiencing.
We’re looking at how to address this hole (and others in the current request chain implementation) in a more long-term way right now, but I don’t have an ETA.
Apologies for the back and forth on this. We’ve got another dev who’s getting ramped up now, so I’m hoping we’ll have a much better process and predictability around all this soon.
@Narayane Yeah, the caching on custom network transports is basically broken at the moment, so that would make sense. The current workaround is to write a custom interceptor for your network usage similar to the default Network interceptor but using your own networking.
I’m working on a longer-term fix but this is something that was missed through the RFC and Beta processes so there’s a decent amount of rethinking that needs to be done there, unfortunately 😭
@designatednerd A preliminary run using 0.37.0: it looks like the cache+watchers work as expected! Thanks. 😃
@dhritzkiv That makes sense, the network stack and how it interacts with the cache changed completely in 0.34.0.
Apologies, I’ve been under the weather. I’m gonna do some digging starting tomorrow to try to figure out how I broke this without breaking the tests 🙃