[
https://issues.apache.org/jira/browse/KAFKA-20879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110091#comment-18110091
]
Hrishi Baskaran edited comment on KAFKA-20879 at 8/31/26 10:22 PM:
-------------------------------------------------------------------
I've looked into this. It doesn't seem like a difficult change from an
implementation standpoint: mainly just updating the consumer,
StoreChangelogReader, to wire in the reason when calling onRestoreSuspended to
its delegating StateRestoreListener.
The issue is that this will be a backwards breaking change unless we use this
ugly alternative approach:
We could add another interface (maybe
StateRestoreListenerWithReasonForSuspended) that extends StateRestoreListener
that has a method overload and then do a type assertion in StoreChangelogReader
to decide which method to call? Another issue with this is that we'll break
client code that uses the more extensive
StateRestoreListenerWithReasonForSuspended if we decide to do a backwards
breaking change and add the additional functionality in the base
StateRestoreListener class itself.
[~mjsax] I'm thinking of writing a KIP for this but am wondering which approach
we should take? I could write about them both and leave it up to community
discussion.
was (Author: JIRAUSER314400):
I've looked into this. It doesn't seem like a difficult change from an
implementation standpoint: mainly just updating the consumer,
StoreChangelogReader, to wire in the reason when calling onRestoreSuspended to
its delegating StateRestoreListener.
The issue is that this will be a backwards breaking change unless if this ugly
alternative approach:
We could add another interface (maybe
StateRestoreListenerWithReasonForSuspended) that extends StateRestoreListener
that has a method overload and then do a type assertion in StoreChangelogReader
to decide which method to call? Another issue with this is that we'll break
client code that uses the more extensive
StateRestoreListenerWithReasonForSuspended if we decide to do a backwards
breaking change and add the additional functionality in the base
StateRestoreListener class itself.
[~mjsax] I'm thinking of writing a KIP for this but am wondering which approach
we should take? I could write about them both and leave it up to community
discussion.
> Consider to add a `SuspendReason` to `StateRestoreListener#onRestoreSuspended`
> ------------------------------------------------------------------------------
>
> Key: KAFKA-20879
> URL: https://issues.apache.org/jira/browse/KAFKA-20879
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: Matthias J. Sax
> Assignee: Hrishi Baskaran
> Priority: Minor
> Labels: needs-kip
>
> ## Description
> When an active task's restoration is interrupted,
> `StateRestoreListener.onRestoreSuspended` is called, but it does not say why.
> There are three reasons it can happen, and they are indistinguishable to the
> application:
> - the task was assigned to another instance,
> - the task was demoted to a standby task on this instance,
> - this instance is shutting down.
> The sibling callback on the other listener does distinguish them.
> `StandbyUpdateListener.onUpdateSuspended` receives a `SuspendReason`. An
> application that follows both listeners to track where its tasks live
> therefore gets a cause for a replica that stops updating, but none for an
> active task that stops restoring.
> ### Scope: only a task that is still restoring
> This is limited to an active task that had **not** finished restoring. If a
> task is RUNNING and there is no restoration in progress, there is nothing for
> a restore listener to report, and the resulting standby task is reported
> through `StandbyUpdateListener.onUpdateStart` as usual. So overall it's a
> rare case, but still worth to address.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
