Retrying RoundTripper leaks a connection on every retry

An http.Response.Body that's never closed doesn't just leak memory -- Go's net/http transport can't return the underlying TCP connection to its connection pool until the body is closed, so a leaked body means a leaked connection. Under light, ad-hoc testing (a handful of manual requests) this is invisible; under real production load, with every retried request leaking one connection per discarded attempt, this exhausts the transport's connection pool and/or file descriptor limits -- exactly the failure mode most likely to strike during a downstream outage, which is also exactly when this package's retry logic is under the most load and doing the most retrying. This is the same class of failure the project's own RoundTripper doc comment specifically calls out avoiding ("drain and close it so its connection can be reused, rather than leaking it").

Every time RoundTripper.RoundTrip starts a new attempt, it's supposed to drain and close the previous (discarded) attempt's response body before replacing it. It now only drains it.

// see test/task13_test.go for the full countingBody / scriptedTransport setup rt := retry.NewRoundTripper(mockTransportReturning(503, 503, 200), policy) resp, _ := rt.RoundTrip(req) fmt.Println(closedCount) // got: 0, want: 2 (the two discarded 503 responses)

Resource leaks in error/retry paths are notoriously easy to introduce (the "happy path" -- one successful attempt, no discarding -- never exercises this code at all) and notoriously hard to notice without either a dedicated test or a production incident with connection pool exhaustion symptoms.

Find where a previous lastResp is discarded inside RoundTrip's retry closure (right before starting a new attempt) -- it does an io.Copy to drain the body. Compare this to what the same block's own doc comment above it says should happen.