App crash: Fatal Exception: retrofit2.j: HTTP 404

[sin-ka]

[REQUIRED] Step 2: Describe your environment

• Android Studio version: Android Studio Bumblebee | 2021.1.1 Patch 2
• Firebase Component: Performance
• Component version: com.google.firebase:firebase-perf:20.0.5

[REQUIRED] Step 3: Describe the problem

Steps to reproduce:

Since the rollout of Firebase Performance on production we recognized a decrease of our crash free rate. The reason seems like to be within the perf sdk itself:

Fatal Exception: retrofit2.j: HTTP 404 
       at retrofit2.KotlinExtensions$await$2$2.onResponse(KotlinExtensions.kt:53)
       at retrofit2.OkHttpCall$1.onResponse(OkHttpCall.java:161)
       at com.google.firebase.perf.network.InstrumentOkHttpEnqueueCallback.onResponse(InstrumentOkHttpEnqueueCallback.java:71)
       at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
       at java.lang.Thread.run(Thread.java:923)

Looks like possible IOExceptions which can result in com.google.firebase.perf.network.InstrumentOkHttpEnqueueCallback.onResponse are not catched?

[argzdev]

Hi @sin-ka, thanks for reporting. It is possible that the IOExceptions is not being caught. Do you have any code snippet where you used firebase-perf that you can share with us?

[sin-ka]

Hi @argzdev. Thanks for the quick response.

We are using custom traces in the way the documentation recommends it https://firebase.google.com/docs/perf-mon/custom-code-traces?platform=android#add-custom-code-traces

We have a central class which manages the start and stop of different custom traces:

 private val firebasePerformanceInstance: FirebasePerformance by lazy {
        FirebasePerformance.getInstance()
    }

... 

 fun startTraces(@NonNull traceNames: List<String>) {
        if (Debug.isDebuggerConnected()) {
            return
        }
        traceNames.forEach { traceName ->
            if (traces[traceName] == null) {
                val trace: Trace = firebasePerformanceInstance.newTrace(traceName)
                trace.start()
                traces[traceName] = trace
                Log.d(TAG, "starting trace $traceName")
            }
        }
    }

    fun stopTraces(@NonNull traceNames: List<String>) {
        traceNames.forEach { traceName ->
            val trace = traces[traceName]
            trace?.let { safeTrace ->
                safeTrace.stop()
                traces[traceName] = null
                Log.d(TAG, "stopping trace $traceName")
            }
        }
    }

You mean starting and stopping the tracing through the sdk should be enclosed by a try catch statement? As far as I see it correct the call FirebasePerfOkHttpClient.sendNetworkMetric(...) can throw an IOException within onResponse in InstrumentOkHttpEnqueueCallback. Should this be handled on client or sdk side?

[argzdev]

Thanks for the code snippet, @sin-ka. I’ll consult with an engineer to check if the fix has to be handled on the sdk or client side.

In the meantime, can you share a bit more code so I can try to reproduce this issue, and context on what you were tracing that encountered this issue?

[sin-ka]

Hey @argzdev, there is acutally not much left but the activites/fragments can trigger the above functions to track any custom traces. Specifically when the view is resumed, traces will be started and stopped when the view is paused at the latest.

[jposuna]

Hey @sin-ka, those exceptions should be caught by the client - as an SDK, we don't want to be silently catching exceptions that the client might want to handle.

However, I'm curious about the increase in the number of exceptions having increased after integrating with Firebase Performance. As far as I can tell, just adding the SDK shouldn't affect the number of exceptions being thrown by network requests. Your screenshot shows that it's a 404 being returned, but the Firebase Performance sdk just sends the request to the end-point defined in your code, so it shouldn't be causing more 404s to be happening. The only thing I can think of is that some other code changed at the same time, or that the endpoint was changed / had some issues at the same time as the release.

One possibility is that your code is catching a subclass of IOException and that these are thrown at a higher level from the Firebase Performance SDK (e.g. HttpRetryException vs IOException). Take a look to see if this could be the cause.

If you have any other information that helps us debug this, please send it on. From what I have right now, it seems unlikely that the increase is caused by the SDK.

[sin-ka]

Hey @jposuna thanks for the update. I will investigate the mentioned points and check if we maybe have some issues on an endpoint, which is triggered by the sdk.

[archie94]

Hello!

In our app we are not using any custom traces still get these crashes occasionally. What would be the recommended way to handle these exceptions?

[OlehHaidaienko]

I think that @jposuna is right. I got the same crash but after an investigation, found that I have an unhandled API call using Retrofit and Coroutines which returns a 404 code. Adding try/catch block fixed the crash in my case

[argzdev]

HI all, it seems that this issue has been resolved and is working as intended. That said, I'll close this now. Thanks!