[
https://issues.apache.org/jira/browse/KAFKA-16032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lianet Magrans updated KAFKA-16032:
-----------------------------------
Description:
OffsetFetch and OffsetCommit handle errors separately. There are some issues to
review around this, to ensure that we keep propagating the same exceptions as
the legacy consumer:
1. Ensure same behaviour of legacy coordinator for expected commit errors:
propagating the error.exception(), or CommitFailedException, depending on the
error (Ex. commit requests that fail with FENCED_INSTANCE_ID or
UNKNOWN_MEMBER_ID should throw a CommitFailedException instead of the error
specific ones)
2. Ensure same behaviour of legacy coordinator for unexpected errors: all
unexpected should fail with KafkaException, even if retriable.
3. Consider if we could unify the error handling for both, commit and fetch?
(Downside, even though there are common errors, there are some that are not
handled similarly in both requests (ex. UNKNOWN_TOPIC_OR_PARTITION throwing a
non-retriable KafkaException for fetch requests, but throwing a retriable
UnknownTopicOrPartitionException for commit requests).
was:
OffsetFetch and OffsetCommit handle errors separately. There are 2 issues to
review around this:
1. Ensure that we keep the legacy behaviour of handling expected errors, and
failing with KafkaException for all unexpected errors (even if retriable).
2. Ensure that we keep throwing the same exception as the legacy coordinator,
which are not always the error.exception(). Ex. commit requests that fail with
FENCED_INSTANCE_ID or UNKNOWN_MEMBER_ID fail in the legacy coordinator with
CommitFailedException instead of the error specific ones.
3. Consider if we could unify the error handling for both, commit and fetch?
(Downside, even though there are common errors, there are some that are not
handled similarly in both requests (ex. UNKNOWN_TOPIC_OR_PARTITION throwing a
non-retriable KafkaException for fetch requests, but throwing a retriable
UnknownTopicOrPartitionException for commit requests).
> Review client errors thrown on OffsetFetch and OffsetCommit failures
> --------------------------------------------------------------------
>
> Key: KAFKA-16032
> URL: https://issues.apache.org/jira/browse/KAFKA-16032
> Project: Kafka
> Issue Type: Sub-task
> Components: clients, consumer
> Reporter: Lianet Magrans
> Assignee: Lianet Magrans
> Priority: Major
> Labels: kip-848-client-support
> Fix For: 3.8.0
>
>
> OffsetFetch and OffsetCommit handle errors separately. There are some issues
> to review around this, to ensure that we keep propagating the same exceptions
> as the legacy consumer:
> 1. Ensure same behaviour of legacy coordinator for expected commit errors:
> propagating the error.exception(), or CommitFailedException, depending on the
> error (Ex. commit requests that fail with FENCED_INSTANCE_ID or
> UNKNOWN_MEMBER_ID should throw a CommitFailedException instead of the error
> specific ones)
> 2. Ensure same behaviour of legacy coordinator for unexpected errors: all
> unexpected should fail with KafkaException, even if retriable.
> 3. Consider if we could unify the error handling for both, commit and fetch?
> (Downside, even though there are common errors, there are some that are not
> handled similarly in both requests (ex. UNKNOWN_TOPIC_OR_PARTITION throwing a
> non-retriable KafkaException for fetch requests, but throwing a retriable
> UnknownTopicOrPartitionException for commit requests).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
