In a Go daemon whose open socket count climbs every push cycle, how do you tell an unclosed resp.Body from an undrained one?

### Two bugs with one symptom A long-running daemon that pushes samples to a remote endpoint on a timer is the ideal shape for both of these mistakes, because it makes the same call thousands of times an hour and the response is something nobody looks at. Two different defects produce "our socket count is going up": **Bug one: the body is never closed.** Somewhere there is a path — usually the early return on a bad status code, sometimes a decode error, sometimes a request built in a helper that returns the response to a caller who forgets — where `resp.Body.Close()` never runs. Each of those requests permanently retains a connection. Nothing reclaims it: there is no finalizer on a response body. **Bug two: the body is closed but never read.** The daemon checks `resp.StatusCode`, closes, and moves on. Every connection is released correctly, but on HTTP/1 the Transport cannot pool a connection whose remaining payload was never consumed, so it discards it and the next push dials again. ### Telling them apart from the outside Count and shape, not count alone. * **Unclosed** looks monotonic. The number of established connections from the process to that endpoint rises roughly in step with the number of requests and never comes back down. Restarting is the only thing that clears it. Steady-state memory creeps up alongside it because each connection carries buffers and bookkeeping. * **Undrained** looks like churn. Live connection count stays low — often around one per concurrent request — but the *rate* of new connections tracks the request rate exactly, and sockets pile up in the kernel's post-close states rather than in the process. The process-level socket count fluctuates instead of climbing to the ceiling. A snapshot taken twice, ten minutes apart, distinguishes them immediately: if the number roughly doubled with load, it is the leak; if it is the same number and the *connection establishment* rate is what is high, it is the reuse failure. ### Telling them apart from the inside `net/http/httptrace` answers the reuse question directly and cheaply, in the program itself: ```go trace := &httptrace.ClientTrace{ GotConn: func(info httptrace.GotConnInfo) { if !info.Reused { newConns.Add(1) } }, } req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace)) ``` `GotConnInfo.Reused` is true when the Transport took the connection out of its idle pool. If a healthy client is doing sequential pushes to one host and `Reused` is false every single time, the connection is not surviving the request, and the body handling is the first place to look. A goroutine profile is the complementary check for the unclosed case: leaked HTTP/1 connections keep their reader goroutines alive, so a growing count of goroutines parked in the Transport's read loop points at bodies that were never closed. ### The fixes are not the same For the unclosed body: make the close unconditional and structural, not something each caller remembers. Arrange the request in one place, `defer` the close immediately after the error check, and check status afterwards. If the function hands the response to a caller, document who owns the close — or better, do not hand a live body across a package boundary at all; read what you need and return that. For the undrained body: drain before closing, but bound it. ```go defer func() { _, _ = io.Copy(io.Discard, io.LimitReader(resp.Body, 64<<10)) resp.Body.Close() }() ``` The bound matters here more than usual. The endpoint in this scenario returns a large buffer nobody reads; transferring megabytes on every push to save one handshake is a worse deal than the handshake. Cap the drain, take the reuse when the leftover is small, and pay for a re-dial when it is not. ### What recent Go changes and what it does not On Go 1.27, closing an HTTP/1 response body drains a bounded amount automatically so the connection can still be pooled. That quietly fixes the undrained case for small bodies, which means an upgrade can make this class of problem disappear — and it also means the version of Go a service is built with is now part of the diagnosis. It does nothing for a body that is never closed, and nothing for a remainder larger than the bound. ### The judgment behind the fix The reason to separate the two before touching code is that they justify different work. The unclosed body is a correctness bug that will eventually take the process down and deserves an immediate, structural fix. The undrained body is a cost problem: it wastes handshakes and ephemeral ports and adds latency, and how much you should spend to fix it depends on the request rate and on how big the wasted remainder is. Someone new to the codebase who sees "sockets climbing" and reaches for a bigger descriptor allowance has treated the second bug as the first, and postponed rather than fixed either.