eduwercamacaro commented on code in PR #14735:
URL: https://github.com/apache/kafka/pull/14735#discussion_r1394297063
##########
streams/src/main/java/org/apache/kafka/streams/processor/internals/TaskManager.java:
##########
@@ -701,7 +706,15 @@ private StandbyTask convertActiveToStandby(final
StreamTask activeTask, final Se
}
private StreamTask convertStandbyToActive(final StandbyTask standbyTask,
final Set<TopicPartition> partitions) {
- return activeTaskCreator.createActiveTaskFromStandby(standbyTask,
partitions, mainConsumer);
+ final StreamTask streamTask =
activeTaskCreator.createActiveTaskFromStandby(standbyTask, partitions,
mainConsumer);
+ final ProcessorStateManager stateManager = standbyTask.stateManager();
+ for (final TopicPartition partition : partitions) {
+ final ProcessorStateManager.StateStoreMetadata storeMetadata =
stateManager.storeMetadata(partition);
+ if (storeMetadata != null && storeMetadata.endOffset() != null) {
+ standbyTaskUpdateListener.onUpdateSuspended(partition,
storeMetadata.store().name(), storeMetadata.offset(),
storeMetadata.endOffset(), StandbyUpdateListener.SuspendReason.PROMOTED);
Review Comment:
I have a theory. We can figure out the `SuspendReason` for `#unregister`
method using `ChangelogState`.
When method `#unregister` is called, `StoreChangelogReader` can consider a
standby task to be `MIGRATED` when the task's `ChangelogState` is in the
`RESTORING` state and `PROMOTED` when it is in `REGISTERED` state. Since it can
be inferred in this instance, we don't need to provide a new argument for the
`#unregister` method.
This is based on what I discover from the code, I may be missing something,
so I should probably double check this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
