[
https://issues.apache.org/jira/browse/KAFKA-19613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18017196#comment-18017196
]
Uladzislau Blok edited comment on KAFKA-19613 at 8/30/25 5:20 PM:
------------------------------------------------------------------
[~FliegenKLATSCH] I checked this on unit test, fetch is empty here. I think we
need to confirm how broker behaves in this case, and verify if this is a case
when broker will send us response with correct and corrupted messages
[~lianetm]
I check the broker code and have a question:
AbstractFetcherThread#processFetchRequest has this comment just after catch for
corrupted message exception:
//we log the error and continue. This ensures two things
// 1. If there is a corrupt message in a topic partition, it does not bring the
fetcher thread
// down and cause other topic partition to also lag
// 2. If the message is corrupt due to a transient state in the log
(truncation, partial writes
// can cause this), we simply continue and should get fixed in the
subsequent fetches
Case 2 looks for me as retriable error. Are you sure, this is not retriable?
FYI: this comment is from 2018, so I believe it can be outdated, just want to
be sure
was (Author: JIRAUSER309258):
[~FliegenKLATSCH] I checked this on unit test, fetch is empty here. I think we
need to conform how broker behave in this case, and verify if this is a case
when broker will send us response with correct and corrupted messages
[~lianetm]
I check the broker code and have a question:
AbstractFetcherThread#processFetchRequest has this comment just after catch for
corrupted message exception:
//we log the error and continue. This ensures two things
// 1. If there is a corrupt message in a topic partition, it does not bring the
fetcher thread
// down and cause other topic partition to also lag
// 2. If the message is corrupt due to a transient state in the log
(truncation, partial writes
// can cause this), we simply continue and should get fixed in the
subsequent fetches
Case 2 looks for me as retriable error. Are you sure, this is not retriable?
FYI: this comment is from 2018, so I believe it can be outdated, just want to
be sure
> Expose consumer CorruptRecordException as case of KafkaException
> ----------------------------------------------------------------
>
> Key: KAFKA-19613
> URL: https://issues.apache.org/jira/browse/KAFKA-19613
> Project: Kafka
> Issue Type: Improvement
> Components: clients
> Reporter: Uladzislau Blok
> Assignee: Uladzislau Blok
> Priority: Minor
> Labels: need-kip
> Attachments: corrupted_records.excalidraw.png
>
>
> As part of analysis of KAFKA-19430 , we decided it would be useful to expose
> root case of consumer request failure (e.g. currently we see just
> KafkaException instead of CorruptRecordException)
> The idea is to not change public API, but expose root case as a filed of
> KafkaException
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
