dd-sdk-android

dd-sdk-android copied to clipboard

Thanks for taking the time for reporting an issue!

Describe what happened My Android app launched a call that returned a 304, and datadog RUM session resource says it has a 200 status instead of a 304.

Steps to reproduce the issue: Have e-tags server side

Describe what you expected: Hi guys! I hope you're doing fine! I was recently investigating something in my project, and I found out datadog is not reporting 304 status on some requests. You have an example here

x-datadog-origin: rum x-datadog-parent-id: 6329686970868304213 x-datadog-sampling-priority: 1 x-datadog-trace-id: 8589955483293502493

(I have the AS screenshot of the request, but I can't share it publicly, give me an email, and I'll get back to you)

I've also asked my teammates on iOS to look at it because I think they might have the same problem.

Have a great day.

Additional context

• Android OS version: Any
• Device Model: Any
• Datadog SDK version: 1.11.1
• Versions of any other relevant dependencies (OkHttp, …): okHttpVersion (4.9.0)
• Proguard configuration: Can't disclose
• Gradle Plugins: Can't disclose

Hi @pietrini, thank you for reporting the issue. We will check internally on both platforms to see if we can reproduce it. We might get back to you for some more information in case we will not be able to track this on our end. Will keep you posted.

@pietrini you mentioned you will check this also on iOS, do you have any feedback from your team ? It will be very helpful for us to have this information as I checked in our code and everything seems to be fine.

I have asked, and I have more insights on iOS because we enabled this first here. I've found that for resources like images, it works, but for standard JSON, we have the same problem.

@pietrini Thanks for the info, we opened a ticket on our end to properly investigate this and we will probably work on this in the next weeks. We will get back here with more information once we have it.

Hi @pietrini, this behaviour is kind of expected.

A 304 status code signals that the ressource you're requested didn't change and that the cached version should be used. This is done to avoid transferring data for nothing. What happens is that on the network layer, OkHttp knows it has a previous version of the URL you're requesting, and when it receives the 304, it converts it to a 200 and returns the cached response. This is why our tracker understands the resource as 200 when your backend returned a 304. A similar mechanism do appear in iOS as well.

We'll keep investigating to see if there's a way for us to reflect this 304 to 200 conversion in some way.

Ok, understood; thanks for the investigation!

It's indeed a tricky problem if OkHttp "lies" about the status 😄

Should I close this ticket as it's not a bug and create a new one with the "enhancement" label?

Have a great day!

We can keep this one hear, I'll change the label.

Hey! Running into the same issue. Any workaround to filter these in the RUM explorer? ~I've seen that their size is tracked around 18 bytes. Not fully confident though on this.~

We don't have a workaround yet, but we'll keep you updated as soon as we have more info