Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Expose whether a response was served from cache on HttpResponseInfo

Open
#4,005 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
1-2 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
android, kotlin

Research direction

Start by reading the HttpResponseInfo and RumResourceAttributesProvider APIs, then inspect how DatadogInterceptor records RUM resources and how the OkHttp and Cronet integrations represent cached responses. The issue gives no file paths or tests, so first locate those entry points and their tests. Done means HttpResponseInfo can report whether the response came from cache across supported clients; consider whether skipping resources for responses that never reached the network belongs in scope.

Written by the indexing model from the issue text.

Description

With the move to HttpRequestInfo/HttpResponseInfo, RumResourceAttributesProvider can no longer tell whether a response hit the network. The deprecated okhttp3.Response overload is the only way to read networkResponse.

OkHttp answers CacheControl.FORCE_CACHE misses with a synthetic 504 Unsatisfiable Request (only-if-cached), and serves disk-cache hits locally. DatadogInterceptor records both as RUM resources. In our production Android app, about 84% of native resources were these synthetic 504s. We drop them by tagging networkResponse == null in the deprecated overload and returning null from setResourceEventMapper.

Request: a network-agnostic flag on HttpResponseInfo, such as isFromCache (OkHttp: networkResponse == null; Cronet: UrlResponseInfo.wasCached()). Ideally, also an option to skip RUM resources for responses that never reached the network.

Related: #3365 (body access added via peekBody).

Dominant language
Kotlin
Stars
227
Forks
87
Avg merge
1d 17h
Merged PRs (30d)
68

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from DataDog/dd-sdk-android

All issues in DataDog/dd-sdk-android

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.