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

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

Start at the errorHandler implementation and trace the generated synchronous and asynchronous service methods described in the issue, including their thenApply/thenApplyAsync paths. Verify the non-2xx flow reads status, headers, and the error body inside response.use, while 2xx responses remain open for later parsing. Done means typed exceptions still propagate and responses close even when error-body parsing throws.