fix: enable TraceOn will cause OOM when putting a large object - #2251

No actionable comments were generated in the recent review. 🎉

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

The title reads fine as-is; two small wording fixes would make the description accurate:

fix: enable TraceOn will cause OOM when putting a large object
fix #1771
before pr:
<img width="1355" height="384" alt="image" src="https://github.com/user-attachments/assets/8043328c-bbec-43a5-b2e3-e244ceaa0fcd" />
we can see max memory is 10GB and CPU is 100%
with this pr:
<img width="553" height="746" alt="image" src="https://github.com/user-attachments/assets/8e7b6cde-3dc9-47b5-8c92-f2e10411092a" />
we can see max memory is 26MB and CPU is 34%

• "memery" → "memory" in both measurement lines.
• The auto-generated release-note bullet says tracing "no longer displays request body contents" — request bodies were never shown in traces: DumpRequestOut is called with body=false and always trimmed the body from the returned dump. What this PR actually changes is that the dump no longer buffers a body-sized dummy in memory while producing the header-only trace. Something like "HTTP tracing no longer buffers a request-body-sized dummy in memory when tracing uploads" would describe it accurately for release notes.

Took another pass over this against master and it looks solid — nothing to change.

The mechanism holds up end to end. With body=false, httputil.DumpRequestOut asks outgoingLength(req) for the size, and when the body is non-nil with a set Content-Length it installs a Content-Length-sized neverEnding('x') dummy reader and buffers the whole thing into the dump before slicing it off (net/http/httputil/dump.go). Swapping in http.NoBody drives outgoingLength to 0, so no dummy body is generated and only the header is dumped — which is exactly the goal.

Two things I checked specifically so this can't bite later:

• The mutation is harmless to the actual transfer. dumpHTTP runs only after httpClient.Do(req) has returned, and executeMethod builds a fresh *http.Request via newRequest() on every retry attempt — so setting req.Body = http.NoBody can't truncate the upload that was sent, nor a retried one.
• The response side is already safe. DumpResponse(resp, false) uses failureToReadBody{}/emptyBody rather than a Content-Length-sized dummy, so large GETs don't have the symmetric problem. The request-only fix is complete.

And the regression test does what it claims — I ran it both ways:

go vet, gofumpt -d, and a full-package go test -c are all clean. 👍