You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Hartmut Armbruster (Jira)" <ji...@apache.org> on 2025/03/15 17:11:00 UTC
[jira] [Updated] (KAFKA-18972) Custom Processor supplied on addReadOnlyStateStore is not used when restoring state from topic
[ https://issues.apache.org/jira/browse/KAFKA-18972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hartmut Armbruster updated KAFKA-18972:
---------------------------------------
Description:
As a Streams Developer, I have added a custom read-only state store ([KIP-813|https://cwiki.apache.org/confluence/display/KAFKA/KIP-813%3A+Shareable+State+Stores]) via {{Topology#addReadOnlyStateStore(_)}} to my Topology, using a custom Processor for state updates ({{{}ProcessorSupplier<KIn, VIn, Void, Void> stateUpdateSupplier{}}}).
*Expected behaviour:* As per JavaDocs, "the Processor should contain logic to keep the StateStore up-to-date". Therefore, it should be used for processing and persisting every event, both in _RUNNING_ state for new events and during state restoration (directly from the source topic).
*Actual behaviour:* During state restoration, events are written directly to the store, bypassing the Processor entirely.
Here's a related discussion on community slack:
[https://confluentcommunity.slack.com/archives/C48AHTCUQ/p1741617964189859?thread_ts=1741539889.829939&cid=C48AHTCUQ]
There was a similar bug fixed recently for GlobalStore -> https://issues.apache.org/jira/browse/KAFKA-7663
was:
As a Streams Developer, I have added a custom read-only state store (Topology#addReadOnlyStateStore(_)) to my Topology, using a custom Processor for state updates (ProcessorSupplier<KIn, VIn, Void, Void> stateUpdateSupplier).
*Expected behaviour:* As per JavaDocs, "the Processor should contain logic to keep the StateStore up-to-date". Therefore, it should be used for processing and persisting every event, both in _RUNNING_ state for new events and during state restoration (directly from the source topic).
*Actual behaviour:* During state restoration, events are written directly to the store, bypassing the Processor entirely.
Here's a related discussion on community slack:
[https://confluentcommunity.slack.com/archives/C48AHTCUQ/p1741617964189859?thread_ts=1741539889.829939&cid=C48AHTCUQ]
There was a similar bug fixed recently for GlobalStore -> https://issues.apache.org/jira/browse/KAFKA-7663
> Custom Processor supplied on addReadOnlyStateStore is not used when restoring state from topic
> ----------------------------------------------------------------------------------------------
>
> Key: KAFKA-18972
> URL: https://issues.apache.org/jira/browse/KAFKA-18972
> Project: Kafka
> Issue Type: Bug
> Components: streams
> Affects Versions: 3.8.0, 3.9.0, 3.8.1
> Reporter: Hartmut Armbruster
> Priority: Major
>
> As a Streams Developer, I have added a custom read-only state store ([KIP-813|https://cwiki.apache.org/confluence/display/KAFKA/KIP-813%3A+Shareable+State+Stores]) via {{Topology#addReadOnlyStateStore(_)}} to my Topology, using a custom Processor for state updates ({{{}ProcessorSupplier<KIn, VIn, Void, Void> stateUpdateSupplier{}}}).
> *Expected behaviour:* As per JavaDocs, "the Processor should contain logic to keep the StateStore up-to-date". Therefore, it should be used for processing and persisting every event, both in _RUNNING_ state for new events and during state restoration (directly from the source topic).
> *Actual behaviour:* During state restoration, events are written directly to the store, bypassing the Processor entirely.
> Here's a related discussion on community slack:
> [https://confluentcommunity.slack.com/archives/C48AHTCUQ/p1741617964189859?thread_ts=1741539889.829939&cid=C48AHTCUQ]
> There was a similar bug fixed recently for GlobalStore -> https://issues.apache.org/jira/browse/KAFKA-7663
--
This message was sent by Atlassian Jira
(v8.20.10#820010)