I feel like this is a noob question, but maybe I'm...

# squarelibraries

[Colton Idle]

I feel like this is a noob question, but maybe I'm missing something basic? My mind kinda goes towards rxdogtag so maybe something like that just exists for coroutines (all of the network calls seem to be suspend functions) So I joined a new project recently and am a lone dev trying to pick up the pieces. our most popular crash on crashlytics is

Non-fatal Exception: java.io.IOException: canceled due to retrofit2. HttpException: HTTP 503
at okhttp3. internal.connection. RealCall$AsyncCall. run (RealCall. kt : 530)
at java. util. concurrent. ThreadPoolExecutor. runWorker (ThreadPoolExecutor. java: 1145)
at java. util. concurrent. ThreadPoolExecutor$Worker. run (ThreadPoolExecutor. java: 644)
at java. lang. Thread. run (Thread. java: 1012)

but im confused on how to take anything actionable from that. There's literally no other information. Is there someway to update the app so that I can get a stacktrace to a callsite in the app code?

[efemoney]

Coroutines offers stack trace recovery, is this called via coroutines? |My understanding is that it should hve the original threads trace too

In the worst case anyways Retrofit embeds information about the called service method inside of the okhttp request as Invocation tags, so that you can just write an interceptor that’ll pull it out from the request tag & rewrite the Response.message of all failed requests with that information

[alex.krupa]

Crashlytics lets you log regular messages that are included in crash/non-fatal/ANR reports (there's a "Logs" tab in the dashboard). Combine that with the above-mentioned interceptor + info you get from it.

[alex.krupa]

To make sure, is it an actual crash or a non-fatal (i.e. a logged exception)? Just asking because the stack trace starts with "Non-fatal".

[Colton Idle]

Ooooh. Did I mess up? Maybe this is in fact not a crash. lol. oh boy. let me check

[Colton Idle]

ah. there is a similar one that is a fatal/crash.

[Colton Idle]

Fatal Exception: retrofit2.HttpException: HTTP 503
at retrofit2.KotlinExtensionsSawait$2$2.onResponse(KotlinExtensions.kt: 53)
at retrofit2.OkHttpCall$1.onResponse (OkHttpCall. java: 161)
at okhttp3.internal.connection.RealCall$AsyncCall. run(RealCall.kt: 519)
at java.util. concurrent. ThreadPoolExecutor. runWorker (ThreadPoolExecutor. java: 1145)
at java. util. concurrent. ThreadPoolExecutor$Worker.run(ThreadPoolExecutor. java:644)
at java. lang. Thread. run (Thread. java:1012)

[alex.krupa]

If there are both then it could just mean that some of those exceptions are caught and some are not. In a mobile app you should probably handle them as early as possible, either manually or with a Retrofit CallAdapter.

Since these are 503 — maybe you could investigate these from the backend side (assuming it's developed at your company)?

[Colton Idle]

Yeah, the issue is that there's a ton of networking code and I legit have no idea where these are coming from.

[Colton Idle]

so weird to me that it just goes back to a ThreadPoolExecutor without somehow telling me where in the app code this happened

[Pablichjenkov]

The first one looks like a non-fatal the second looks like a crash but it doesn't seem to log the full exception cause

[Colton Idle]

yeah. the first one i posted here by accident. i meant to post the second one. which is fatal. and somehow has 0 info about who called it.

[Colton Idle]

I wonder if that means its something weird like a globalScope.launch or something.

[Pablichjenkov]

The crash seems to happen in a background thread inside okhttp , it doesn’t get caught in your code because is out of your hands. It seems to be initiated on okhttp side and you have no control of it. What version of okhttp is the project using?
You can try asking in squarelibraries

[efemoney]

This is #squarelibraries lol, but yeah okhttp manages its own threads in a pool that run the network calls. If you want control over that you could specify a custom Dispatcher to your okhttp builder that allows you to configure the thread where the Call is run.

[Colton Idle]

I wonder if maybe I can make a miminimal repro of this. I'm still confused how it doesn't give me a stacktrace back to my callsite in the app.

[Colton Idle]

i feel like in all my years of using okhttp and retrofit and coroutines i never encountered something like this. thanks for the help. ill do some more digging and report back

[Pablichjenkov]

Perhaps the device ran out of RAM or a bug in crashlytics. I have seen cryptic/cutout logs before

[efemoney]

> I’m still confused how it doesn’t give me a stacktrace back to my callsite in the app
Because its run on a different thread … *stack*trace is based on the current (thread) call stack

[efemoney]

Coroutines add special behavior (see stacktrace recovery) to be able to mitigate this and show you calls across the entire coroutine (which could span multiple threads)