https://kotlinlang.org logo
#squarelibraries
Title
# squarelibraries
c

Colton Idle

11/13/2023, 3:36 PM
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
Copy code
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?
e

efemoney

11/13/2023, 4:37 PM
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
1
a

alex.krupa

11/13/2023, 5:58 PM
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.
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".
c

Colton Idle

11/13/2023, 6:05 PM
Ooooh. Did I mess up? Maybe this is in fact not a crash. lol. oh boy. let me check
ah. there is a similar one that is a fatal/crash.
Copy code
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)
a

alex.krupa

11/13/2023, 7:01 PM
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)?
c

Colton Idle

11/13/2023, 7:34 PM
Yeah, the issue is that there's a ton of networking code and I legit have no idea where these are coming from.
so weird to me that it just goes back to a ThreadPoolExecutor without somehow telling me where in the app code this happened
p

Pablichjenkov

11/13/2023, 7:39 PM
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
c

Colton Idle

11/13/2023, 9:08 PM
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.
I wonder if that means its something weird like a globalScope.launch or something.
p

Pablichjenkov

11/14/2023, 5:37 AM
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
e

efemoney

11/14/2023, 1:04 PM
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.
😅 1
👍 1
c

Colton Idle

11/14/2023, 2:14 PM
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.
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
p

Pablichjenkov

11/14/2023, 2:24 PM
Perhaps the device ran out of RAM or a bug in crashlytics. I have seen cryptic/cutout logs before
e

efemoney

11/14/2023, 2:25 PM
> 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
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)
today i learned 2
2 Views