Search before asking
Description
PbApiVersion carries api_key, min_version, max_version as int32 for forward-compat, but both clients use them as int16/short internally. Today:
- Java silently truncates with (short) intValue. A server advertising e.g. api_key = 70000 becomes 4464, a different (probably invalid) API key — with no signal to the operator.
- Rust panics via i16::try_from(...).unwrap(). A misbehaving server can crash a client connection task by advertising any value outside i16 range.
Both behaviors are wrong. Better: validate at the wire boundary and surface a typed protocol error (e.g. InvalidApiVersionException / Error::UnsupportedVersion) carrying the offending field name and value, then close the connection. No panic, no silent corruption.
Trivial change in both clients, should land together to keep cross-language behavior aligned.
Lower priority as this has low chances to happen in practice
Willingness to contribute
Search before asking
Description
PbApiVersion carries api_key, min_version, max_version as int32 for forward-compat, but both clients use them as int16/short internally. Today:
Both behaviors are wrong. Better: validate at the wire boundary and surface a typed protocol error (e.g. InvalidApiVersionException / Error::UnsupportedVersion) carrying the offending field name and value, then close the connection. No panic, no silent corruption.
Trivial change in both clients, should land together to keep cross-language behavior aligned.
Lower priority as this has low chances to happen in practice
Willingness to contribute