From 36d4e680fc4519cd9560ca3f197f7602eb441442 Mon Sep 17 00:00:00 2001 From: "abhishek.jha" Date: Wed, 2 Jul 2025 16:51:47 -0700 Subject: [PATCH] Modify ScheduleToStartTimeout error catching --- service/history/task/timer_active_task_executor.go | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/service/history/task/timer_active_task_executor.go b/service/history/task/timer_active_task_executor.go index 90a84bc770e..275f8b19459 100644 --- a/service/history/task/timer_active_task_executor.go +++ b/service/history/task/timer_active_task_executor.go @@ -391,7 +391,7 @@ Loop: // check if it's possible that the timeout is due to activity task lost if timerSequenceID.TimerType == execution.TimerTypeScheduleToStart { domainName, err := t.shard.GetDomainCache().GetDomainName(mutableState.GetExecutionInfo().DomainID) - if err == nil && activityInfo.ScheduleToStartTimeout >= int32(t.config.ActivityMaxScheduleToStartTimeoutForRetry(domainName).Seconds()) { + if err == nil && activityInfo.ScheduleToStartTimeout > int32(t.config.ActivityMaxScheduleToStartTimeoutForRetry(domainName).Seconds()) { // note that we ignore the race condition for the dynamic config value change here as it's only for metric and logging purpose. // theoratically the check only applies to activities with retry policy // however for activities without retry policy, we also want to check the potential task lost and emit the metric