hubcio opened a new pull request, #3766:
URL: https://github.com/apache/iggy/pull/3766

   An application built on this SDK cannot reach a command its SDK build
   has never heard of. operation_for_code ended None => InvalidCommand,
   so a code absent from COMMAND_TABLE failed at encode time, before any
   byte left the process, and a server that does implement it never got
   the chance to answer. COMMAND_TABLE is a protocol registry, not a
   per-server capability list, so the server is the authority on whether
   a code exists: an unknown code now ships as non-replicated, carrying
   the code in RequestHeader.reserved, and the server answers with a
   proper error if it does not know it.
   
   The SDK no longer second-guesses that classification either. It used
   to refuse a code the registry knows as replicated, but the server
   re-derives the class from the same registry and denies a mismatch on
   a path that commits nothing, so the client check duplicated a guard
   it does not own. It was unreachable besides, since every replicated
   entry resolves through from_command_code first, and it was the sole
   construction of an UnknownReplicatedCommand variant nothing in the
   tree consumed. operation_for_code is now infallible, the raw-command
   documentation no longer explains consensus to callers, and error code
   14002 is retired rather than reused.
   
   The client-side namespace derivation goes with it. The server
   re-derives the namespace from the request body, and resolves named
   identifiers and Balanced or MessagesKey partitioning that the SDK
   refused outright, so the client copy was redundant and weaker. Not a
   pure deletion: out-of-range stream, topic and partition ids are now
   rejected by the server rather than before the request leaves the
   process, and a partition op using Balanced or MessagesKey no longer
   fails fast client-side.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to