[jira] [Commented] (KAFKA-20879) Consider to add a `SuspendReason` to `StateRestoreListener#onRestoreSuspended`

["Hrishi Baskaran (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-20879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110091#comment-18110091 ] 

Hrishi Baskaran commented on KAFKA-20879:
-----------------------------------------

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)