[
https://issues.apache.org/jira/browse/KAFKA-20880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18101721#comment-18101721
]
Eduwer Camacaro commented on KAFKA-20880:
-----------------------------------------
I also consider this to be an inconsistency in these two callbacks that track
the restoration of state stores for both active and standby tasks.
Additionally, it is weird to me that we didn't notice that the Javadoc for the
tasksId argument on the StandbyUpdateListener#batchUpdated method when
implementing the KIP.
However, I don't think the TaskId is irrelevant information on these callbacks
because it allows the users to add trace, debug, or info log entries that print
the restoration lag of the stores that are inside of a single task.
Additionally, users might want to add a metric that groups the total
restoration lag for all the stores in the task.
I understand that the TaskId is not a concept that users should usually need to
worry about, but sometimes it is useful for users to understand some
information about the assigned tasks on a single instance, so I propose to
solve this by adding the TaskId argument for both `StateRestoreListener` and
`StandbyUpdateListener`.
> Consider to address inconsistency in `StandbyUpdateListener` API
> ----------------------------------------------------------------
>
> Key: KAFKA-20880
> URL: https://issues.apache.org/jira/browse/KAFKA-20880
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: Matthias J. Sax
> Priority: Minor
> Labels: needs-kip
>
> Kafka Streams has two state-restore-listeners: `StateRestoreListener` and
> `StandbyUpdateListener`.
> `StandbyUpdateListener#onBatchLoaded()` is the only method that has a
> `TaskId` parameter. It's unclear why we have this inconsitency.
> Technically, `TaskId` should not be relevant, because the listener is for a
> store, not a task, it would fire for all stores for a task. And
> `TopicPartition` and `storeName` are already passed in which is the more
> relevant information.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
