fix: don't fail responses whose body was capped by -response-size-to-read

[dogancanbakir]

Fixes #2641

What

A response whose body was capped by -response-size-to-read (or by the default 50MB cap) was reported as status_code: 0, failed: true with ContentLength=100194 with Body length 10.

The cap itself is intentional: since 78bf9c3 the body is wrapped in a LimitReader before pdhttputil.DumpResponseHeadersAndRaw, so building resp.Raw cannot load an unbounded body or an infinite stream in memory. The side effect was not: that dump calls resp.Write(), and net/http refuses to serialize a response whose body is shorter than the advertised Content-Length, so httpx treated our own truncation as a transport error and dropped the whole result.

When the truncation is ours (ContentLength > MaxResponseBodySizeToRead), that serialization error is now tolerated. Headers and the truncated body are already dumped correctly at that point, so resp.Raw stays usable. The cap is untouched, memory stays bounded, and a server genuinely lying about Content-Length still errors as before.

Verification

TestDoTruncatedBodyIsNotAFailure fails without the fix (ContentLength=4096 with Body length 10) and passes with it. Full ./common/httpx/... suite is green.

Against the URL from the issue:

before: error "ContentLength=100194 with Body length 10", status_code 0, failed true
after:  status_code 200, content_length 100194, failed false

raw_header keeps Content-Length: 100194 and the body holds the bytes actually read.

Summary by CodeRabbit

• Bug Fixes
  • Large HTTP responses that exceed the configured read limit are now handled successfully instead of being reported as failures.
  • Truncated response bodies retain their status and advertised content length while respecting the configured maximum size.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Essentials

Run ID: 5a723f8a-0b08-4b7d-b8d7-4079a4e4ada3

📥 Commits

Reviewing files that changed from the base of the PR and between 9d9e315 and 4a057ae.

📒 Files selected for processing (2)

• common/httpx/httpx.go
• common/httpx/response_memory_test.go

Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

Walkthrough

Do now recognizes intentional response-body truncation and ignores its resulting content-length mismatch. A regression test verifies successful responses, preserved metadata, retained headers, and capped body size.

Changes

Truncated response handling

Layer / File(s)	Summary
Truncation detection and error handling common/httpx/httpx.go	Detects when the configured read limit is below the advertised content length. Ignores the resulting mismatch error while preserving existing handling for other errors.
Truncation regression coverage common/httpx/response_memory_test.go	Verifies successful status, preserved content length and headers, and capped response-body size when truncation occurs.

Estimated code review effort: 2 (Simple) | ~10 minutes

Severity of issue fixed: Medium

Suggested reviewers: mzack9999

Merge Risk: ⚪ Minimal · up to 4a057

Capped responses now retain their successful HTTP status and metadata while keeping the configured body-size limit. The regression coverage shows no actionable merge-blocking risk remains.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the primary fix: responses truncated by -response-size-to-read are no longer treated as failures.
Linked Issues check	✅ Passed	The implementation meets issue #2641. It preserves successful response metadata when intentional truncation causes the expected Content-Length mismatch, while continuing to handle genuine mismatches a…
Out of Scope Changes check	✅ Passed	All changes support the linked issue. The code change adjusts intentional truncation handling, and the added test verifies the reported regression. No unrelated changes are present.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 2 files.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix-truncated-body-not-failure

---

_{A rabbit trims the stream with care
The status stays bright and fair
Headers keep their measured tale
While capped bytes fill the pail
No false failure joins the run
The response hops beneath the sun}

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