ryerraguntla commented on code in PR #4258:
URL: https://github.com/apache/iggy/pull/4258#discussion_r4077898958
##########
gateways/kafka/src/bridge/error.rs:
##########
@@ -163,7 +172,17 @@ const fn iggy_error_to_kafka_code(err: &IggyError) -> i16 {
| IggyError::TcpError
| IggyError::TransientNotAccepted => ERROR_NOT_LEADER_OR_FOLLOWER,
IggyError::TransientNotCommitted => ERROR_REQUEST_TIMED_OUT,
- IggyError::TooManyPartitions => ERROR_INVALID_PARTITIONS,
+ // Not `ERROR_INVALID_PARTITIONS` (37): that code's own text, per
`kafka-protocol`'s
+ // table, is "Number of partitions is below 1" - the opposite
condition from "too many"
+ // (Iggy's server-side cap, above 1000). Reusing 37 for both
directions would return a
+ // client-visible error message that contradicts the actual request it
sent.
+ IggyError::TooManyPartitions => ERROR_INVALID_REQUEST,
+ // The operation *did* commit - the SDK's own reconnect path replayed
a write whose first
+ // attempt already applied, and the server's client-table dedup caught
the replay. Falling
+ // into the catch-all below would report a permanent server fault for
a request that
+ // actually succeeded; a Java client treats `UNKNOWN_SERVER_ERROR` as
non-retriable and
+ // would surface a spurious failure for a `CreateTopics` that in fact
created the topic.
+ IggyError::RequestAlreadyApplied => ERROR_NONE,
Review Comment:
RequestAlreadyApplied => ERROR_NONE moved out of the shared
iggy_error_to_kafka_code (every handler's error path) into a local match arm in
CreateTopics' own write call — the only place "the write already applied" is a
meaningful fact.
--
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]
