{"id":746,"date":"2026-10-04T13:40:00","date_gmt":"2026-10-04T11:40:00","guid":{"rendered":"https:\/\/grindloop.io\/blog\/?p=746"},"modified":"2026-10-03T13:39:32","modified_gmt":"2026-10-03T11:39:32","slug":"okhttp-interceptor-illegalstateexception-closed","status":"publish","type":"post","link":"https:\/\/grindloop.ai\/blog\/okhttp-interceptor-illegalstateexception-closed\/","title":{"rendered":"Why Reading the Response Body in an OkHttp Interceptor Throws IllegalStateException: closed"},"content":{"rendered":"

An OkHttp interceptor that calls response.body.string()<\/code> and then returns the same response causes IllegalStateException: closed<\/code> one step later. The crash comes from the next reader, usually Retrofit’s converter or your own code. Two causes stack here. First, string()<\/code> is a terminal read. It pulls the whole body into memory and then closes the one-shot source behind it. Second, the interceptor hands back the original Response<\/code> object. The caller reads from the same source the interceptor just closed. Okio checks for that on every read and throws the bare word “closed”. Rebuilding the body from the string stops the crash. It also buffers every response, file downloads included, in memory. The fix is response.peekBody(limit)<\/code>. It reads a bounded copy and leaves the original body unread. Apply it only to JSON responses, so streaming bodies pass through untouched.<\/p>\n\n

A session check that breaks every API call<\/h2>\n\n

The running example is a feed app. Its backend reports an expired session with HTTP 200 and an error field in the JSON. So a developer adds an application interceptor that looks for \"session_expired\"<\/code> and logs the user out.<\/p>\n\n\n

class SessionExpiredInterceptor(private val onExpired: () -> Unit) : Interceptor {\n    override fun intercept(chain: Interceptor.Chain): Response {\n        val response = chain.proceed(chain.request())\n        val json = response.body.string()          \/\/ reads AND closes the body\n        if (\"\\\"session_expired\\\"\" in json) onExpired()\n        return response                            \/\/ hands back a closed body\n    }\n}\n\nval client = OkHttpClient.Builder()\n    .addInterceptor(SessionExpiredInterceptor { sessionManager.logout() })\n    .build()<\/pre>\n\n\n
We ran this against a MockWebServer on OkHttp 5.5.0 with Kotlin 2.4.20. The server returned {\"items\":[1,2,3]}<\/code>. The caller read the body after execute()<\/code>. The status line came through fine. The body read failed.<\/p>\n\n\n
code=200\njava.lang.IllegalStateException: closed<\/pre>\n\n\n
The same snippet on OkHttp 4.12.0, with body!!<\/code> in place of body<\/code>, threw the same exception. In a Retrofit app, the reader is the converter. A Chucker issue filed in January 2020<\/a> shows that trace. GsonResponseBodyConverter.convert<\/code> fails inside okio.RealBufferedSource.read<\/code> because an earlier interceptor had closed the body.<\/p>\n\n
string() reads the whole body and then closes it<\/h2>\n\n
The ResponseBody<\/code> source in OkHttp 5.5.0<\/a> calls the class a one-shot stream from the server. A live socket backs it, or an open file for cached responses. Its KDoc lists string()<\/code> and bytes()<\/code> among the calls that close the body. The implementation shows why. string()<\/code> wraps source()<\/code> in Kotlin’s use<\/code> block. It reads the bytes into a String<\/code>, then use<\/code> closes the source.<\/p>\n\n
So string()<\/code> consumes the body and releases it. No second copy is left for a later reader. Once it returns, the bytes exist only in the String<\/code> the interceptor kept.<\/p>\n\n
Why the next reader throws IllegalStateException: closed<\/h2>\n\n
The second cause is the return response<\/code> line. chain.proceed()<\/code> gives the interceptor a Response<\/code>. The interceptor passes that same object up the chain. Nothing in between copies the body. The caller’s response.body<\/code> is the body the interceptor just closed.<\/p>\n\n
The caller’s first read hits Okio’s RealBufferedSource<\/code><\/a>. Its read methods start with a check(!closed)<\/code> whose message is just “closed”. That’s why the exception carries one word and no hint about the interceptor.<\/p>\n\n
The two causes need each other. A string()<\/code> call with nothing reading afterward is fine. Returning the response without reading it is fine too. The crash needs a terminal read in one layer and a second reader in another. The bug also turns up in debugging tools that add their own interceptor. A Flipper issue from April 2022<\/a> reports its network interceptor throwing the same exception. Another interceptor earlier in the chain had closed the response.<\/p>\n\n
Rebuilding the body from the string buffers every download<\/h2>\n\n
The common first fix keeps the String<\/code> and wraps it in a new body.<\/p>\n\n\n
val json = response.body.string()\nif (\"\\\"session_expired\\\"\" in json) onExpired()\nreturn response.newBuilder()\n    .body(json.toResponseBody(response.body.contentType()))\n    .build()<\/pre>\n\n\n
It works. In our run, the caller read all 40,013 characters of a large JSON body. The cost shows up on every other response. This interceptor runs for every call on the client, including image and file downloads. The ResponseBody<\/code> KDoc warns that string()<\/code> loads the entire body into memory. It says a very large body may trigger an OutOfMemoryError<\/code>. A download that used to stream to disk now sits in the heap as a decoded String<\/code> first.<\/p>\n\n
Peek a bounded copy, and only for JSON responses<\/h2>\n\n\n
private const val MAX_PEEK = 16L * 1024\n\nclass SessionExpiredInterceptor(private val onExpired: () -> Unit) : Interceptor {\n    override fun intercept(chain: Interceptor.Chain): Response {\n        val response = chain.proceed(chain.request())\n        if (response.body.contentType()?.subtype != \"json\") return response\n        val head = response.peekBody(MAX_PEEK).string() \/\/ copy, original stays unread\n        if (\"\\\"session_expired\\\"\" in head) onExpired()\n        return response\n    }\n}<\/pre>\n\n\n
Response.peekBody<\/code><\/a> calls peek()<\/code> on the body’s source. It copies up to byteCount<\/code> bytes into a separate buffer and returns that buffer as a new ResponseBody<\/code>. The original source keeps its bytes. Calling string()<\/code> on the copy closes only the copy. The KDoc warns that the peeked bytes are loaded into memory. It suggests a modest limit. It also says calling peekBody<\/code> after the body is consumed is an error. So the order inside the interceptor matters.<\/p>\n\n
We sent three responses through the fixed client. They were a normal feed, a session error and a 100,000-byte application\/octet-stream<\/code> file.<\/p>\n\n\n
\/feed code=200 length=17 start={\"items\":[1,2,3]}\nlogging out\n\/feed code=200 length=27 start={\"error\":\"session_expired\"}\n\/file code=200 length=100000 start=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<\/pre>\n\n\n
The file skipped the peek because of the content type check. A separate run sent a 40,013-byte JSON body. The peek stopped at 16,384 bytes. The caller still read all 40,013. The cap only limits what the interceptor sees. So it works when the error field sits near the start of a small error body. If the error could appear past the cap, raise the cap for that endpoint rather than dropping it.<\/p>\n\n
HttpLoggingInterceptor<\/code> avoids the crash in a similar way. In its 5.5.0 source<\/a>, the BODY<\/code> level calls source.request(Long.MAX_VALUE)<\/code> to buffer the entire body. Then it logs from buffer.clone()<\/code>. The caller still gets an unread source. That costs memory for every logged body, the same tradeoff as the rebuild fix.<\/p>\n\n
If the backend can return 401 for an expired session, an OkHttp Authenticator<\/code><\/a> handles it instead. Its KDoc describes reactive authentication after a challenge from the server. No interceptor has to read the body then.<\/p>\n\n
Walking the interviewer from the crash to the fix<\/h2>\n\n
This snippet fits the debugging round, where you get working code with one planted failure. Hass explains what the debugging round scores after the first fix<\/a>. A strong answer goes in this order.<\/p>\n\n
    \n
  1. Name the reader that fails. The status code arrives. Then the first body read throws, so something closed the body between the network and the caller.<\/li>\n
  2. Give the first cause. string()<\/code> is a one-shot read that closes the source when it finishes.<\/li>\n
  3. Give the second cause. The interceptor returns the same Response<\/code>, so the caller reads the closed source. Okio’s check(!closed)<\/code> produces the message.<\/li>\n
  4. Offer the rebuild fix, then name its cost yourself. It buffers every body on the client, downloads included.<\/li>\n
  5. Land on peekBody<\/code> with a cap and a content type check. Then ask whether the server can send 401, so an Authenticator<\/code> can replace the body check entirely.<\/li>\n<\/ol>\n\n
    Fixes that stop the crash and leave a bug<\/h2>\n\n