You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Matthias J. Sax (Jira)" <ji...@apache.org> on 2026/06/04 19:17:00 UTC
[jira] [Updated] (KAFKA-20663) KIP-1035: stale persisted changelog offset causes OffsetOutOfRangeException/TaskCorruptedException on restart
[ https://issues.apache.org/jira/browse/KAFKA-20663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthias J. Sax updated KAFKA-20663:
------------------------------------
Affects Version/s: (was: 4.3.1)
(was: 4.4.0)
> KIP-1035: stale persisted changelog offset causes OffsetOutOfRangeException/TaskCorruptedException on restart
> -------------------------------------------------------------------------------------------------------------
>
> Key: KAFKA-20663
> URL: https://issues.apache.org/jira/browse/KAFKA-20663
> Project: Kafka
> Issue Type: Bug
> Components: streams
> Affects Versions: 4.3.0
> Reporter: Bill Bejeck
> Assignee: Bill Bejeck
> Priority: Blocker
> Fix For: 4.3.1
>
>
> In 4.3, KIP-1035 moved the changelog offset into RocksDB and removed the forced flush on commit, so the persisted offset is now only made durable by an organic memtable flush or a clean close. When that offset goes stale — after an unclean exit, or a clean shutdown followed by changelog truncation/compaction while the instance is down — and the changelog log-start offset has advanced past it, the restore consumer seeks out of range and throws OffsetOutOfRangeException, which Streams converts to a TaskCorruptedException (full local-state wipe and rebuild). This happens far more often than in 4.2 (where the forced flush kept the offset within roughly commit.interval.ms), affecting both at-least-once and exactly-once and hitting windowed/segmented stores hardest.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)