Chunked responses don't get recorded with OkHttp3

Our team has noticed that some of our responseBody values are empty or null on our Android app; our network stack is effectively OkHttp3 (we use it through a custom Volley HttpStack). We’re on v3.12.1 of OkHttp3 and there’s no caching or websockets involved in the responses in question

Upon setting the AgentLog to AUDIT, we noticed the NR agent was logging from OkHttp3TransactionUtil that responses weren’t being recorded because the body or content-length was missing. Upon closer inspection, we were able to confirm that our response bodies were indeed not missing but the Content-Length response header was not returned from our servers because they’re streaming the responses via the Transfer-Encoding: chunked response header. I debugged through several internal classes of the NR agent to determine that it’s not prebuffering responses in this case and will never report the response bodies if the Content-Length is not explicitly sent. Specifically, instrumentation.okhttp3.ResponseBuildExtension no longer utilizes instrumentation.okhttp3.PrebufferedResponseBody to prebuffer responses. After checking subsequent internal NR agent code for HttpUrlConnection and OkHttp2, the issue appears to be unique to OkHttp3 instrumentation

I noticed a post from January 2017 where someone complained about download progress being misreported because New Relic was prebuffering the response; the NR team responded by issuing an update as v5.12.1 to disable this. It was only disabled for OkHttp3 while all other supported network stacks were able to keep this functionality

Unfortunately, this has the side-effect of breaking our legitimate usecase where downloads aren’t being utilized, just normal HTTP API calls. Additionally, there’s now different behavior depending on the network stack. Is there anything the NR team can do fix our issue? For the meantime, we’re switching back to HttpUrlConnection in production but this isn’t ideal as we’d prefer to not block our migration to Retrofit2 (which implicitly uses OkHttp3)

If necessary, I can create a sample project to demonstrate this

Hey @jon.amireh,

A reproduction case would be amazing! I can share your repro and detailed post with our engineering team for a closer investigation.

1 Like

I’ve created a sample project on GitHub to reproduce the issue with either an OkHttp MockWebServer or one of our own services

1 Like

Thank you for providing your sample project! I created a ticket with our mobile team, including all of this information. I’ll update you as soon they’ve had a chance to review.

1 Like

Hey @jon.amireh,

I’ve received a response from our engineer that reviewed your case:

Looks like a legit issue, and super-kudos to the customer for providing a reproduction case. I created a story to investigate, but I don’t have an exact estimate on when this will be complete.

If it is a result of recent changes to the agent, they could try version 5.25.2 and see if that helps.

Thanks @dmurray!

As for the workaround, unfortunately, the issue was introduced in NR v5.12.1 and downgrading to v5.12.0 is not an option because our project now uses the Android Gradle Plugin v4.0 and NR support for said plugin began in v5.26.0

As I said, we’ll deploy a version of our app with HttpUrlConnection as a workaround but we’re eager for a fix from the Android agent team so definitely let us know when that happens.

@dmurray, our team is still waiting on an update to this issue. Is there anything that can be shared at this time as to when this bug will be fixed?

Hey @jon.amireh
It looks like this our engineering team still has this investigation open, and I don’t yet have updates on their progress. I will continue to track this however, and post here as soon as an update is available.


1 Like