apollo-kotlin
apollo-kotlin copied to clipboard
apollographql
Fatal Exception: java.lang.IllegalStateException Found: TERMINATED, but expected [ACTIVE, CANCELED] v.2.5.11
We continue to see this crash in Firebase but don't see any stacktrace that references our Android mobile app's code:
Fatal Exception: java.lang.IllegalStateException
Found: TERMINATED, but expected [ACTIVE, CANCELED]
com.apollographql.apollo.internal.RealApolloCall.responseCallback (RealApolloCall.java:367)
com.apollographql.apollo.internal.RealApolloCall$1.onFetch (RealApolloCall.java:287)
com.apollographql.apollo.internal.fetcher.CacheFirstFetcher$CacheFirstInterceptor$1.onFetch (CacheFirstFetcher.java:48)
com.apollographql.apollo.internal.interceptor.ApolloCacheInterceptor$1.run (ApolloCacheInterceptor.java:60)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1167)
java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:641)
java.lang.Thread.run (Thread.java:920)
-
Is this actually crashing our app if there's no reference to our codebase, or could it just be bug that Firebase is showing a bug as a crash?
-
Is there a poor design that could be causing this error to be thrown in our app?
I know these questions are broad but we're trying to get to the bottom of why this crash is showing in Firebase and have not been able to reproduce in testing.
Hi 👋 Thanks for sending this!
- Is this actually crashing our app if there's no reference to our codebase, or could it just be bug that Firebase is showing a bug as a crash?
The Fatal Exception: in these logs would indicate that it's crashing your app although it's hard to be 100% sure.
- Is there a poor design that could be causing this error to be thrown in our app?
Good question. I'm not 100% sure. If you have the bandwidth for, it'd be interesting to try moving to Apollo Kotlin 3. If not, having a reproducer would help tremendously. Things to watch out for are cancellations. Maybe try to open/close your app really quick or these kind of things?
Thanks for the quick response! When you say 'reproducer', do you just mean reproducing the crash? Currently attempting that with login/logout, app restart, etc. Or did you mean any additional check in our Apollo implementation?
Migrating to Apollo Kotlin 3 will hopefully fix this issue going forward, we just need to get the bandwidth for it.
When you say 'reproducer', do you just mean reproducing the crash?
Yup, ideally a small minimal reproducible example that reproduces the crash. Without this, it's really hard to tell where the issue comes from.
Any possible update or ideas that may cause this issue? If we are wrapping our calls in try/catch blocks what could be a possible reason we are still not catching this exception? We still continue to see this crash in Analytics but cannot reproduce.
It's really hard to tell. It might take a while to investigate and given it's most likely fixed in 3.x it's going to be hard to prioritize.
Looks like the onCompleted() callback is called before the onFetch() one. Do you use query batching and/or APQ? This may have a slightly different lifecycle than other queries so that could be something to look into.
Also, if you can make a fork, I'd try returning Optional.absent() instead of throwing there: https://github.com/apollographql/apollo-kotlin/blob/92aa7b56b1bb268e95fdf93811dc61821d090bd6/apollo-runtime/src/main/java/com/apollographql/apollo/internal/RealApolloCall.java#L366
I'm almost certain this would hide the issue (albeit not the root cause)
Do you use query batching and/or APQ? This may have a slightly different lifecycle than other queries so that could be something to look into.
I don't believe we are but I am not too familiar in this area.
Also, if you can make a fork, I'd try returning
Optional.absent()instead of throwing there:
That's pretty straight forward. I went ahead and made a small PR and tagged you. I don't see this change having any adverse effects, besides just hiding the root cause like you mentioned. Thanks again for your time.