[sarankumar1325]

What this PR does:

decompressRequest caps the request reader at maxSize+1 bytes, but the deferred size check only fired when reading or unmarshalling also returned an error. A body that got cut at the cap on a message boundary was accepted with the extra data silently dropped. This happens with uncompressed bodies that have no Content-Length, and with gzip bodies, where the compressed size is under the limit but the decompressed size is over it.

Changes:

• pkg/util/http.go: always reject a body longer than maxSize, even if reading it did not fail.
• pkg/util/http.go: decompressFromBuffer (the httpgrpc path, where the body comes in as a *bytes.Buffer) had no Gzip case and returned a nil body, so gzip requests on this path were treated as empty. It now decodes gzip with the same maxSize+1 cap.
• pkg/util/push/otlp.go: the OTLP JSON branch reads the body itself, so it gets the same check.

With this change, oversize requests return 400 received message larger than max (...) instead of a partial write.

Tests:

• TestParseProtoReader_GzipDecompressionBomb now checks for the size error. Before, it only checked for some error; it passed because of an incidental illegal tag unmarshal error.
• New TestParseProtoReader_OversizeBodyIsRejected covers uncompressed and gzip streams and gzip in a bytes.Buffer. It checks every limit between the encoded size and the decompressed size. Without the fix it fails: the body is accepted at message boundaries, and the buffered gzip path decodes 0 series.
• New TestOTLPWriteHandler_OversizeBodyIsRejected covers protobuf and JSON, each uncompressed and gzip. All 4 subtests fail without the fix.
• go test -tags "netgo slicelabels" ./pkg/util/ ./pkg/util/push/, go vet and gofmt all pass.

AI disclosure (per GENAI_POLICY.md): I used an AI coding assistant for most of this change. I checked the diff and the tests myself, and confirmed the tests fail before the fix and pass after it.

Which issue(s) this PR fixes:
Fixes #7900

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]
• docs/configuration/v1-guarantees.md updated if this PR introduces experimental flags

[sandy2008]

Thanks for fixing #7900. The fix looks right to me: the deferred check in decompressRequest now rejects any read that hit the maxSize+1 cap, the new Gzip case in decompressFromBuffer decodes httpgrpc bodies with the same cap, and the OTLP JSON branch gets the same check, all returning 400 like the existing Content-Length check. Remote write and remote read only use RawSnappy, whose decoded length is checked before decoding, so they're unaffected (./pkg/util/push/ and the remote read tests pass). With http.go and otlp.go reverted to master, the bomb test, the gzip over-limit and buffered-gzip subtests of the new util test, and all four new OTLP subtests fail, as they should. Two small things inline.

[sandy2008]

For the noCompression case tc.data is body, so this loop starts at len(body) and runs zero times: "noCompression over limit" passes vacuously, and it still passes with http.go reverted to master. Starting every case at the compressed size keeps the gzip cases as they are and gives the uncompressed stream the same ~5k limits, message-boundary cuts included; with this change the subtest fails on master and passes with the fix.

Suggested change

	for maxSize := len(tc.data); maxSize < len(body); maxSize++ {
	for maxSize := gz.Len(); maxSize < len(body); maxSize++ {

[sandy2008]

Nit: remote write (v1 and v2) and remote read always parse with util.RawSnappy, whose decoded size was already checked against the limit through snappy.DecodedLen, so they never truncated. Only the OTLP handler uses NoCompression/Gzip, so maybe scope the entry to OTLP:

Suggested change

	* [BUGFIX] Distributor: Reject Remote Write and OTLP request bodies whose decompressed size exceeds the configured limit instead of silently truncating them, and decode gzip-compressed bodies received over httpgrpc instead of treating them as empty. #7902
	* [BUGFIX] Distributor: Reject OTLP request bodies whose decompressed size exceeds `-distributor.otlp-max-recv-msg-size` instead of silently truncating them, and decode gzip-compressed OTLP protobuf bodies received over httpgrpc instead of treating them as empty. #7902