fix(net): report the status code when the response body cannot be read - #193
fix(net): report the status code when the response body cannot be read#193JspIIV wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: getoptimum/coderabbit/.coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
Included review availability: 4 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 5 reviews per hour. 📝 WalkthroughWalkthrough
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: 🟡 Moderate · up to The new regression test currently contains a duplicate type declaration, so the test package will not compile and the PR is not merge-ready until that declaration is removed. Suggested reviewers: 🚥 Pre-merge checks | ✅ 8 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (8 passed)
Full details: Scope DisciplineExplanation The pull request changes only Full details: Behavior SafetyExplanation The one-line change preserves Full details: Over-EngineeringExplanation PASS. The production change is a single return-value correction and adds no cache, helper layer, or signature churn. The test uses small local transport/body stubs only to create a deterministic read failure, and it checks observable results: the error, HTTP status, and nil response. It does not assert internal implementation details. Full details: SecurityExplanation PASS — The pull request changes only the returned HTTP status code on response-body read failure and adds a deterministic test. The diff introduces no injection handling, credentials, cryptographic code, sensitive logging, or secrets in manifests. The test uses only the literal status 503 and the error text "connection reset".
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
GetCurl documents that the "status code return as is even in unmarshalling error", and the json.Unmarshal path five lines below does exactly that. The io.ReadAll path returned 0 instead, so a caller that branches on the status could not tell a 503 whose body was truncated from a request that never reached the server at all. This matters for the package's own users: getIPViaTraceURL wraps the result as "request failed, code: %d", which logged code 0 for a server that had in fact answered. Return resp.StatusCode on that path too, matching the sibling error return and the documented contract.
75a7ab4 to
8b401cd
Compare
What
GetCurl's doc comment promises:The
json.Unmarshalfailure path inexecuteRequesthonours that and returnsresp.StatusCode. Theio.ReadAllfailure path five lines above returns0instead.A body read fails on a truncated response, a mid-body connection reset, or a client timeout that expires while the body is streaming — all of which happen against a server that did reply. In those cases the caller sees
0, which is the same value it gets when the request never reached the server, so it cannot tell the two apart or decide whether the status is worth retrying.This already shows up inside the package.
getIPViaTraceURLwraps the result as:with a 10s client timeout, so a slow trace endpoint that answered
200and then stalled mid-body is logged ascode: 0.Fix
Return
resp.StatusCodeon that path too, matching the sibling error return and the documented contract.Test
TestCurlReportsStatusWhenBodyReadFailsuses a stubRoundTripperthat returns a503with a body that fails on firstRead, so it is deterministic and needs no network.Against
mainit fails:With the fix it passes.
Note:
pkg/nethas three pre-existing failures on Windows unrelated to this change —TestGetCurl/TestPostCurl/TestPatchCurlassert the Linux dial error stringconnect: connection refused, while Windows reportsconnectex: No connection could be made.... They fail on untouchedmaintoo. Happy to open a separate issue if that is useful.Summary by CodeRabbit
Bug Fixes
Tests