[
https://issues.apache.org/jira/browse/KAFKA-20879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18111793#comment-18111793
]
Hrishi Baskaran commented on KAFKA-20879:
-----------------------------------------
Oh yeah, I think that would totally work. I guess I was overthinking things.
I'll get the KIP ready
> 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)
