fix: abort incomplete streamed responses

[perfloop]

An upstream body-copy error could previously leave the client with a clean success containing only a prefix. TAG now surfaces the error and aborts a committed direct-streaming response.

The abort happens after operation bookkeeping. A received upstream 2xx still triggers PUT/DELETE cache invalidation or the tiered PUT marker. The write-through tee remains reserved until its asynchronous cache write releases the reservation. HTTP/1.0 uses an abortive TCP close because normal connection close completes an unknown-length body; HTTP/1.1 and HTTP/2 use the standard abort path.

The routed signing-mode ListBuckets test covers HTTP/1.0, HTTP/1.0 over TLS, HTTP/1.1, and HTTP/2 with a chunked upstream 200 missing its terminal chunk. Complete known-length and unknown-length responses, HTTP/1.0 complete responses, and pre-header signature failures remain controls. Response-capture operations use a separate path and are not changed. Production frequency and SDK-specific effects remain unmeasured.

The recorded repair comparison is violated at d460159ba9d215c83b4d5c344b8388618c60face; the final assertion is satisfied. Reproduce it with sh proof/verify_routed_truncation.sh.

Validation included make build, make test, make test-integration, make test-race, make test-coverage, and make lint-ci.

Recorded proof ran with retained support that is not included in this pull request.

Other target checks are S3 Compatibility Tests / s3-compat-tests (default), S3 Compatibility Tests / s3-compat-tests (tiered), S3 Compatibility Tests (Cluster) / s3-compat-tests-cluster (default), Lint PR Title / lint, and CLA Assistant / cla.

---

Generated by Perfloop. Measurements and checks. Reproduce this comparison (tenant access required).

---

Note

Medium Risk
Changes committed-response handling for all direct-streaming paths and alters when PUT/DELETE invalidate cache relative to client-visible errors; incorrect abort logic could break clients or leave stale cache entries.

Overview
Fixes a case where a mid-stream upstream body failure could still look like a successful HTTP response to clients. The forwarder now returns body-copy errors after status and headers are already sent, and handleWithError aborts committed direct-streaming responses (TCP reset on HTTP/1.0/TLS, http.ErrAbortHandler otherwise) instead of appending S3 error XML or finishing framing around a prefix.

Post-forward mutation bookkeeping no longer treats a delivery error as “forward failed”: when upstream already returned 2xx, PUT/DELETE still run cache re-invalidation, tiered upstream markers, and write-through tee work keyed off statusRecorder, while clients may still see a transport/body-read failure. Docs add a Response delivery section describing this split.

Adds integration tests for truncated ListBuckets across HTTP/1.0, TLS, HTTP/1.1, and HTTP/2, plus unit tests for forwarder meta-on-copy-error and invalidation/marker behavior when the response body does not fully reach the client.

^{Reviewed by Cursor Bugbot for commit 712e2b5. Bugbot is set up for automated code reviews on this repo. Configure here.}

[greptile-apps]

Confidence Score: 5/5

[High risk] Changes how streamed responses handle delivery failures.

The PR appears safe to merge; no actionable issue was identified.

Summary

The PR propagates direct-stream body-copy errors to the HTTP handler, aborts committed incomplete responses, and preserves cache bookkeeping after confirmed upstream mutations.

• Adds routed truncation tests across HTTP/1.0, HTTP/1.1, and HTTP/2, plus mutation and write-through tests.
• Documents the client-visible delivery error and mutation semantics.

_{Reviews (1) · Last reviewed commit: "fix: abort incomplete upstream response ..."}