Maybe I'm missing something but is there really a conflict between what you're proposing and v5 spec?
The spec seems to say two things that are immediately relevant to the point about custom payloads in requests: - The default QueryHandler impl just ignores them - Only a few requests currently support custom payloads I read that more as a statement of how things currently are rather than as a prohibition. Put differently: I don't see anything in that language that would lead to a conflict with the spec if other requests started using them. To this point (as you mention) the Java driver doesn't limit handling of custom payload to specific message types in the body. If you include the custom payload flag we'll try to decode it for you <https://github.com/datastax/native-protocol/blob/1.5.2/src/main/java/com/datastax/oss/protocol/internal/FrameCodec.java#L330-L333> regardless of message type. If I misunderstood please set me straight Abe! - Bret - On Wed, Aug 27, 2025 at 10:27 AM Abe Ratnofsky <a...@aber.io> wrote: > The v5 native protocol spec currently only supports custom payloads on > query execution messages: > https://github.com/apache/cassandra/blob/61b3d5a54befe440044ad86159a62fee487229eb/doc/native_protocol_v5.spec#L297-L298 > > > > Currently, only QUERY, PREPARE, EXECUTE and BATCH requests support > custom payloads. > > The Java driver also does not log warnings if they’re provided on other > response message types, even though this is compliant with the spec. > > Any objections to relaxing this restriction, so we can expose warnings and > custom payloads for other protocol messages, like the authentication flow? > This is especially relevant with CEP-50: Authentication Negotiation. Even > just adding support on READY would provide an opportunity for the server to > indicate warnings to clients about protocol initialization issues, like > using a deprecated authenticator. >
