You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Kartikay Dubey (Jira)" <ji...@apache.org> on 2026/05/05 10:32:00 UTC
[jira] [Assigned] (KAFKA-20508) Do not log/throw error/exception for corrupted tasks due to compacted changelog topic
[ https://issues.apache.org/jira/browse/KAFKA-20508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kartikay Dubey reassigned KAFKA-20508:
--------------------------------------
Assignee: Kartikay Dubey
> Do not log/throw error/exception for corrupted tasks due to compacted changelog topic
> -------------------------------------------------------------------------------------
>
> Key: KAFKA-20508
> URL: https://issues.apache.org/jira/browse/KAFKA-20508
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: Herman Kolstad Jakobsen
> Assignee: Kartikay Dubey
> Priority: Minor
>
> The current state store position is tracked in the changelog locally (writing offsets into local {{.checkpoint}} file). If a task is moved to a pod (active or standby), the store offset is used as start offset to restore state. If the offset is too old, ie, smaller than beginning-offset, an error is triggered. Because the store content aged out, and we need to ensure we don't miss any tombstone (which might have cleaned up, too), a restoration based on the full changelog is needed. So we wipe the state store entirely before restoring.
> This scenario is nothing to be worried about as everything is gracefully handled, but when the scenario happens an ERROR is logged together with a TaskCorruptedException.
> The ERROR log is noisy for the users and can confuse the user into taking action when indeed no action should be taken as it is handled by Kafka internals.
> A more suitable log level could then be WARN or INFO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)