[LjungeldTheHelper]

Summary

Adds the changelog entry for #3303 (community fix by @dizider for #3302) as history/latest/3302.md. #3303 itself has no changelog file, so this PR adds it separately. It changes no code.

Entry:

• [client-v2] Fixed INSERT failing with LZ4Exception: maxDestLen is too small (LZ4) or ZstdException: Destination buffer is too small (ZSTD) when request compression is enabled (compressClientRequest(true)) and a 64 KiB block of the data does not compress, for example random bytes. The compressed output buffer was as large as the uncompressed block, but such a block grows when it is compressed. The buffer is now sized with the worst-case bound of the codec (LZ4Compressor.maxCompressedLength, Zstd.compressBound). The bug was introduced in 0.11.0. ([client-v2] Insert fails when request compression is enabled and data is incompressible #3302)

Related: #3302, #3303. The backport to v0.11.0 is a separate PR.

Checklist

• A human-readable description of the changes was provided to include in CHANGELOG

🤖 Generated with Claude Code

---

Note

Low Risk
Documentation-only changelog addition with no runtime or build changes.

Overview
Adds history/latest/3302.md so the fix merged in #3303 is documented in the changelog; this PR does not change application code.

The entry records that client-v2 INSERT with compressClientRequest(true) could fail with LZ4/ZSTD “destination buffer too small” when a 64 KiB chunk does not compress (e.g. random data), because the output buffer matched the uncompressed block size instead of the codec’s worst-case bound. The documented fix uses LZ4Compressor.maxCompressedLength and Zstd.compressBound; the regression is noted from 0.11.0.

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