A modern programming language that makes developers happier.

kotlinlang

Hi everyone - I am trying to track down an ANR which started showing up once we enabled normalized cache (full stacktrace in thread)
`Emitters.kt - com.apollographql.apollo3.cache.normalized.internal.WatcherInterceptor$intercept$$inlined$filter$1$2.emit`

Has anyone encountered a similar issue? Would it make sense to install a different interceptor to dump state periodically in order to track why this happens?
I wonder if this is because we put too many keys into our cache :thinking_face:

```main (runnable):tid=1 systid=32187 
       at java.util.LinkedHashMap.newNode(LinkedHashMap.java:280)
       at java.util.HashMap.putVal(HashMap.java:630)
       at java.util.HashMap.put(HashMap.java:611)
       at java.util.HashSet.add(HashSet.java:219)
       at java.util.AbstractCollection.addAll(AbstractCollection.java:352)
       at java.util.LinkedHashSet.&lt;init&gt;(LinkedHashSet.java:169)
       at kotlin.collections.CollectionsKt___CollectionsKt.toMutableSet(CollectionsKt___CollectionsKt.java:1696)
       at kotlin.collections.CollectionsKt.toMutableSet(CollectionsKt.java:14)
       at kotlin.collections.CollectionsKt___CollectionsKt.intersect(CollectionsKt___CollectionsKt.java:1673)
       at kotlin.collections.CollectionsKt.intersect(CollectionsKt.java:11)
       at com.apollographql.apollo3.cache.normalized.internal.WatcherInterceptor$intercept$$inlined$filter$1$2.emit(Emitters.kt:224)
       at kotlinx.coroutines.flow.SharedFlowImpl.collect$suspendImpl(SharedFlow.kt:383)
       at kotlinx.coroutines.flow.SharedFlowImpl$collect$1.invokeSuspend(SharedFlow.kt:13)
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
       at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
       at android.os.Handler.handleCallback(Handler.java:942)
       at android.os.Handler.dispatchMessage(Handler.java:99)
       at android.os.Looper.loopOnce(Looper.java:226)
       at android.os.Looper.loop(Looper.java:313)
       at android.app.ActivityThread.main(ActivityThread.java:8775)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)```

hmm this doesn't ring a bell. Seems to come from <https://github.com/apollographql/apollo-kotlin/blob/main/libraries/apollo-normalized-cache/src/commonMain/kotlin/com/apollographql/apollo3/cache/normalized/internal/WatcherInterceptor.kt#L35|this line> :thinking_face:

I don't think `changedKeys` nor `watchedKeys` should normally be so huge as to cause an ANR

Do you have a rough idea how many keys we're looking at?

Finally got some time to start digging into this, so far the biggest size that I would observe:
`QueryName: watched keys size: 22 changedKeys: 865`

Perhaps I might be leaking memory somewhere else and this gets throttled :thinking_face:

It doesn't seem astronomically large either

I mean it's significant but a device with 4GB of RAM and some GHz CPU should be able to handle 865 strings in a Set...

<@U79JY5TL3> sorry for calling out, turns out this is a memory leak in our app somewhere else and it's just crashing/freezing when we're reaching to Apollo cache

Glad you found the cause. Thanks for the update!