Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Throwing retrofit2.HttpException HTTP 500 Internal Server Error, although exception is handled #3626

Open
naveenchandan opened this issue Aug 25, 2021 · 8 comments

Comments

@naveenchandan
Copy link

naveenchandan commented Aug 25, 2021

I am using coroutines to call the api, If the response code is 500 then the app is crashing even though I'm catching the exception. Below is the implementation:

interface OnboardingApi {
        @PUT("/verifyOtp")
        suspend fun verifyOtp(@Body verifyOtpRequest: VerifyOtpRequest): Response<VerifyOtpResponse?>
}

override suspend fun verifyOtp(verifyOtpPayload: VerifyOtpPayload): VerifyOtpResponse? {
        try {
            val response = onboardingApi.verifyOtp(
                VerifyOtpRequest(
                    getDeviceDetails(sharedPreferencesHelper),
                    verifyOtpPayload.mobile,
                    verifyOtpPayload.otp
                )
            )
            return if (response.isSuccessful) {
                response.body()
            } else {
                RetrofitUtils.getErrorBody<VerifyOtpResponse>(response.errorBody())
            }
        } catch (e: Exception) {
            e.printStackTrace()
            FirebaseCrashlytics.getInstance().recordException(e)
        }
        return null
    }

and here is the stacktrace of the crash:
Fatal Exception: retrofit2.HttpException: HTTP 500 Internal Server Error
       at retrofit2.KotlinExtensions$await$2$2.onResponse(KotlinExtensions.java:53)
       at retrofit2.OkHttpCall$1.onResponse(OkHttpCall.java:161)
       at com.google.firebase.perf.network.InstrumentOkHttpEnqueueCallback.onResponse(InstrumentOkHttpEnqueueCallback.java:71)
       at okhttp3.RealCall$AsyncCall.execute(RealCall.java:203)
       at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
       at java.lang.Thread.run(Thread.java:764)```
@stepanzalis
Copy link

I have the same issue, any updates on this?

@ptornhult
Copy link

Is this really a Retrofit2 problem or an internal FirebasePerf problem (I'm having the same issue)

@giaesp
Copy link

giaesp commented Dec 9, 2021

I have the same issue with no dependencies on Firebase. The issue is in okhttp: any status code != 200 throws an unhandled exception, causing a crash. Timeout also causes app crash.

@drissfoo
Copy link

drissfoo commented Apr 5, 2022

any update on this still having it ?

@bahacan19
Copy link

any update on this still having it ?

I personally searched in my codebase and then found a code like this in a okhttp3.Authenticator. (inside of its authenticate() method)

someCoroutineScope.launch {
            // a retrofit call gets 4XX
        }

but it needs to have exception handlers:

scope.launch(CoroutineExceptionHandler { _, ex -> logThisException(ex) }) {
            // a retrofit call gets 4XX
        }

this is how i fixed for now.

@flopshot
Copy link

any update on this still having it ?

I personally searched in my codebase and then found a code like this in a okhttp3.Authenticator. (inside of its authenticate() method)

someCoroutineScope.launch {
            // a retrofit call gets 4XX
        }

but it needs to have exception handlers:

scope.launch(CoroutineExceptionHandler { _, ex -> logThisException(ex) }) {
            // a retrofit call gets 4XX
        }

this is how i fixed for now.

If I use that exception handler, I lose the original exception and get

CoroutineCancelationException

I need to recover the original OkHttp exception, which has messages from the server

@softsan
Copy link

softsan commented Apr 6, 2023

Same issue here.. any one found any solution yet?

@JakeWharton
Copy link
Member

Without a failing test case or minimally-reproducing sample project that demonstrates the problem it's impossible to know what's going on. I'll leave the issue open for 30 days in case someone wants to make one of those to aid us in debugging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants