Ok last one for caching I swear :sweat_smile: :thr...

# apollo-kotlin

[Marco Pierucci]

Ok last one for caching I swear 😅 🧵

[Marco Pierucci]

Now that all the entries looks correct I'm trying to use apollo as the source of truth. So I hook up a watcher :

fun workOrder(id: String): Flow<Pair<WorkOrderInfo, List<FetchWorkOrderQuery.ValidFieldsetOption>>> {
        return apolloClient.query(FetchWorkOrderQuery(id = id))
            .fetchPolicy(FetchPolicy.CacheFirst)
            .watch()
            .map {
            ...
            }
    }

And the Have A mutation with an optmistic cache:

apolloClient.mutation(UpdateTaskComponentsMutation(input = newComponents))
            .doNotStore(false)
            .optimisticUpdates(
                UpdateTaskComponentsMutation.Data(
                    UpdateTaskComponentsMutation.UpdateTaskComponents(
                        listOf(
                            UpdateTaskComponentsMutation.Component(
                                __typename = newComponent.componentInfo.__typename,
                                componentInfo = newComponent.componentInfo,
                                id = newComponent.componentInfo.id
                            )
                        )
                    )
                )
            )
            .execute()

This seems to be writing in the cache alright, ( If I re enter the screen I can see the new value)
But for some reason the watch is not emitting?

[Marco Pierucci]

https://www.apollographql.com/docs/kotlin/caching/query-watchers
Could not fin much more here, im goign over video sin youtube to see if I find something

[mbonnin]

Is your new component id the same as the one from the initial query?

[Marco Pierucci]

Yep double checked and its the same ( also checked the db and the entry is corretly updated)

[mbonnin]

You can try make sure your watcher Flow is not cancelled or terminated (maybe add a onCompletion { println("complete) } )

[mbonnin]

Also worth trying to publishing one of the cache keys manually to see if it triggers the watcher (apolloClient.apolloStore.publish(setOf("Component:42")))

[Marco Pierucci]

sure thing, will check

[mbonnin]

If nothing works, good old breakpoint debugging should give more information. The interesting bits are here

[mbonnin]

watch() also takes 2 parameters (I'm assuming you're using v3, right?). You can try setting them to true to make the flow throw on cache misses

[Marco Pierucci]

Cool, publishing did not work either. Will cehck the params and also debug

[Marco Pierucci]

thanks!

[Marco Pierucci]

Ok interestingly enough. After some debug ( thanks for pointing into the right place). It seems I was adding way to many watched keys. I stoped watching one of the flows and now works. Maybe the huge amount was causing some crash that was swallowed

[mbonnin]

Interesting 🤔 Given the amount of RAM that devices have these days, feels like this should work nonetheless

[Marco Pierucci]

Im talking about 4k keys ( if the debuggers was right 😛 )

[mbonnin]

That's like nothing for 2GHz CPU with several GB of RAM

[mbonnin]

What's interesting is that the other flow you were watching is not related to the 1st one?

[Marco Pierucci]

oh thats good to know, maybe Il spend soem more time at udnerstanding as I was a bit worried that we reach a big number anyways

[Marco Pierucci]

What's interesting is that the other flow you were watching is not related to the 1st one?

But they all add watch keys to the pool right?

[mbonnin]

watchedKeys == null || changedKeys.intersect(watchedKeys!!).isNotEmpty()

[mbonnin]

watchedKeys here is local to one query

[Marco Pierucci]

👀

[mbonnin]

changedKeys is whatever changed in the store

[Marco Pierucci]

right, I know a bit better to where look now

[Marco Pierucci]

cheers!