Retrofit loses modified request headers when wrapping okhttp3.Response to retrofit2.Response

[Prithuld]

When an OkHttp interceptor modifies request headers, the modified headers are present in okhttp3.Response.request but are not preserved in retrofit2.Response.raw().request.

Steps to Reproduce:

1. Create an interceptor that modifies request headers:
   updatedReq = originalReq.newBuilder().addHeader("X-Custom-Header", "some-value").build()
   httpResponse = chain.proceed(updatedReq)
2. okhttp3.Response.request has the header ✅
3. retrofit2.Response.raw().request.header("X-Custom-Header") returns null ❌

Expected Behavior:
retrofit2.Response.raw().request should contain the same headers as okhttp3.Response.request (the modified request that was actually sent).

Actual Behavior:
retrofit2.Response.raw().request contains the original request headers (before interceptor modifications).

Impact:
Custom headers added by interceptors cannot be extracted from retrofit2.Response.raw().request, forcing workarounds like adding values to response headers.

[adityaanikam]

I looked into this. Traced retrofit's own path end to end: OkHttpCall.enqueue()'s onResponse(Call, okhttp3.Response rawResponse) passes OkHttp's own response straight into parseResponse() with no intermediate rebuild, and parseResponse()'s only mutation is:

rawResponse = rawResponse.newBuilder().body(new NoContentResponseBody(...)).build();

Response.newBuilder() in OkHttp copies all fields from the source response by default, including request so this specific line shouldn't be the culprit, and retrofit doesn't appear to touch .request anywhere else on this path. That actually rules out OkHttpCall.java itself as where the headers go missing.

Given that, my working theory is this is happening earlier, in the OkHttp interceptor chain itself, before the response ever reaches retrofit's callback e.g. an interceptor higher up the chain (cache interceptor, a redirect following interceptor, or connection reuse handling) rebuilding the response against the pre modification request rather than the one your interceptor produced via chain.proceed(modifiedRequest). That would explain why okhttp3.Response.request looks correct inside your interceptor (right after your own proceed() call) but not by the time it reaches retrofit2.Response.raw().request() further up the chain.

I'd like to dig into this further specifically reproducing with a minimal interceptor stack to see exactly which interceptor's response object first loses the header, since that determines whether this is actually a retrofit issue at all or belongs in OkHttp instead. Will report back with a minimal repro once I've isolated it.