New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle activity retry timer in passive #2640
Conversation
@@ -144,7 +144,7 @@ func (t *transferQueueStandbyTaskExecutor) processActivityTask( | |||
} | |||
|
|||
if activityInfo.StartedId == common.EmptyEventID { | |||
return newPushActivityToMatchingInfo(*activityInfo.ScheduleToStartTimeout), nil | |||
return newPushActivityToMatchingInfo(activityInfo.TaskQueue, *activityInfo.ScheduleToStartTimeout), nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so activityInfo.TaskQueue
always equals to task.TaskQueue?
Do you happen to know why we persist the field in transfer tasks in the first place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to task.TaskQueue
return nil, nil | ||
} | ||
|
||
if activityInfo.Attempt > task.Attempt { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realize we have the same thing in timer active execution. But I am curious why we use >
instead of ==
?
What changed?
Handle activity retry timer in passive
Why?
Case: activity is retrying in source cluster and then failover to target cluster. We should persist the retry timer and handle the timer correctly.
How did you test it?
Unit tests
Potential risks
Is hotfix candidate?