[
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 10:41 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
UPD: I've analyzed broker behavior and in short:
Comment I've mentioned above this is not about reading message from log, but
about appending information for followers, not sure if this is related to
current ticket, but that's the only place in code where I found connection
between CorruptedMessageException
ReplicaManager#read looks to me as it's trying to read max bytes and just fail
if there is any error, but I couldn't find any uses of
CorruptedMessageException in this path
Could you please suggest any broker person to contact with to verify broker
behavior?
was (Author: JIRAUSER309258):
[~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
> 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)
