fix(stdlib): Instrument response body read for chunked HTTP responses#6202
fix(stdlib): Instrument response body read for chunked HTTP responses#6202sentrivana wants to merge 16 commits intomasterfrom
Conversation
The HTTP client span was being finished in getresponse(), which only waits for response headers. For chunked (or large) responses, the actual data transfer happens later during read(), leaving that time uninstrumented. Defer span completion to HTTPResponse.read() for responses with a body, with HTTPResponse.close() as a safety net for responses that are never read. Responses with no body (Content-Length: 0, HEAD, 204, 304) still finish the span immediately in getresponse(). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Codecov Results 📊✅ 13 passed | Total: 13 | Pass Rate: 100% | Execution Time: 8.21s All tests are passing successfully. ❌ Patch coverage is 19.51%. Project has 15021 uncovered lines. Files with missing lines (1)
Generated by Codecov Action |
Codecov Results 📊✅ 6 passed | Total: 6 | Pass Rate: 100% | Execution Time: 1.01s 📊 Comparison with Base Branch
✨ No test changes detected All tests are passing successfully. ❌ Patch coverage is 18.18%. Project has 17057 uncovered lines. Files with missing lines (1)
Coverage diff@@ Coverage Diff @@
## main #PR +/-##
==========================================
- Coverage 22.11% 21.31% -0.8%
==========================================
Files 190 190 —
Lines 21789 21675 -114
Branches 7302 7619 +317
==========================================
+ Hits 4817 4618 -199
- Misses 16972 17057 +85
- Partials 386 385 -1Generated by Codecov Action |
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Drop the `not rv` check from the read() wrapper's span-finishing condition. read(0) legitimately returns b"" without consuming the body, which would falsely trigger span completion. The fp and closed checks are sufficient to detect when the body is fully consumed. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Alex Alderman Webb <alexander.webb@sentry.io>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
There are 2 total unresolved issues (including 1 from previous review).
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 5e768d8. Configure here.

The HTTP client span in the stdlib integration was finishing in
getresponse(), which only waits for response headers, not the actual response. For chunked or large responses, the actual data transfer happens duringread(), leaving that time uninstrumented.Defer span completion to
HTTPResponse.read()for responses with a body (chunked or Content-Length > 0), withHTTPResponse.close()as a safety net for responses that are never read.close()is called). In a sense we're essentially flipping the current situation (where we report requests to be much shorter than they are, since they don't include the response part) -- but the current situation was incorrect for all spans, while thisclose()fallback should hopefully only kick in for edge cases.Responses with no body (Content-Length: 0, HEAD, 204, 304) still finish the span immediately in
getresponse().requestslibrary requests #2277