Non-2xx responses are not closed when error handling throws

[fallintoplace]

Summary

Non-2xx responses can remain open when errorHandler throws typed service exceptions. Service implementations generally call errorHandler.handle(response) before entering the later response.use { ... } parsing block, so thrown error paths bypass the service-level close.

Current flow

Generated service methods commonly follow this shape:

val response = clientOptions.httpClient.execute(...)
return errorHandler.handle(response).parseable {
    response.use { ... }
}

Async service methods have the same ordering inside thenApply/thenApplyAsync.

errorHandler returns successful responses as-is, but for non-2xx statuses it reads the error body and throws without closing the HttpResponse.

Impact

OkHttp response bodies should be closed to release sockets back to the pool. In high-error-rate scenarios, leaving thrown-path responses open can increase connection pool pressure, file descriptor usage, stalled calls, or flaky tests.

Expected behavior

The error handler should own response cleanup on non-2xx paths:

• 2xx: return the response without closing it
• non-2xx: read status, headers, and error body inside response.use { ... }, then throw the typed exception
• still close the response if error body parsing itself throws