apache/cassandra · error · org.apache.cassandra.transport.ProtocolException

Provided frame does not appear to be Snappy compressed

Error message

Provided frame does not appear to be Snappy compressed

What it means

During Snappy decompression the server validates the compressed payload with Snappy.isValidCompressedBuffer before inflating. If the payload fails validation, the frame is not genuinely Snappy-compressed data and this ProtocolException is thrown, closing the connection.

Solutions

Ensure the client actually compresses bodies with Snappy when it negotiates the snappy codec.
Disable compression on the client (compression: null) if compression is not truly needed.
Verify no proxy/middleware alters frame bodies between client and server.
Check client library Snappy framing — write the uncompressed length, then Snappy.compress output.

Example fix

// before: negotiation says snappy but body is plain bytes
frame.compression = 'snappy'; frame.body = plaintext;
// after
frame.body = Snappy.compress(plaintext); // actually compress
frame.compression = 'snappy';

Defensive patterns

Strategy: validation

Validate before calling

boolean isSnappy = Snappy.isValidCompressedBuffer(body, 0, body.length);
if (!isSnappy) throw new IllegalStateException("body sent with snappy compression but is not Snappy-compressed");

Type guard

boolean looksLikeSnappyFrame(byte[] body) { try { return body.length > 0 && Snappy.isValidCompressedBuffer(body, 0, body.length); } catch (Exception e) { return false; } }

Try / catch

try { ... } catch (ProtocolException e) {
    if (e.getMessage().contains("Snappy")) { // disable compression or fix codec usage
    }
}

Prevention

Only enable snappy in connection options if the client actually compresses.
Round-trip test: compress, then validate with isValidCompressedBuffer before sending.
Ensure no proxy strips or re-encodes frame bodies.
Pin client codec library versions compatible with the server (lz4/snappy-java).

When it happens

Trigger: Client negotiates snappy compression but sends a body that is not valid Snappy data — e.g. plaintext sent with compression enabled, or a corrupt/incorrectly framed compressed buffer.

Common situations: Mismatched compression settings (client says snappy, middleware strips compression); custom proxies re-encoding frames; fuzzer traffic.

Understand the failure class

Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.

Related errors

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/8c7d582a766ce15f. Report an issue: GitHub.

Appendix: source

Thrown at src/java/org/apache/cassandra/transport/Compressor.java:116

                output.release();
                throw e;
            }
            finally
            {
                uncompressed.release();
            }

            return uncompressed.with(output);
        }

        public Envelope decompress(Envelope compressed) throws IOException
        {
            try
            {
                byte[] input = CBUtil.readRawBytes(compressed.body);

                if (!Snappy.isValidCompressedBuffer(input, 0, input.length))
                    throw new ProtocolException("Provided frame does not appear to be Snappy compressed");

                int uncompressedLength = Snappy.uncompressedLength(input);
                validateUncompressedLength(uncompressedLength);
                ByteBuf output = CBUtil.allocator.heapBuffer(uncompressedLength);

                try
                {
                    int size = Snappy.uncompress(input, 0, input.length, output.array(), output.arrayOffset());
                    output.writerIndex(size);
                }
                catch (final Throwable e)
                {
                    output.release();
                    throw e;
                }

                return compressed.with(output);
            }

View on GitHub (pinned to 88fd0f6a0e)