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)