retryactivityfailover

func FailOnFirstAttemptActivity ¶

func FailOnFirstAttemptActivity(ctx context.Context, input string) (string, error)

FailOnFirstAttemptActivity runs for activeDuration and then fails with a retriable error on attempt 0; it succeeds immediately on any later attempt.

The attempt-0 run time is load-bearing for the activityretryfailover scenario: it keeps the activity in STARTED state long enough for the standby cluster to observe the started state via SyncActivity and ack its pending ActivityTaskScheduled transfer task. The standby executor re-evaluates a pending task on a hardcoded ~30s backoff (standbyTaskRedispatchInitialInterval in service/history/task/task.go), so the window must comfortably cover one such re-evaluation. If the transfer task were still pending (activity never observed as started) at failover time, the queue-processor restart on failover would replay it as active and re-dispatch the activity, masking the lost-retry-timer bug under test.

func Workflow ¶

func Workflow(ctx workflow.Context, input types.WorkflowInput) (types.WorkflowOutput, error)

Workflow executes a single activity with a retry policy. The activity fails with a retriable error on its first attempt (attempt 0) and succeeds on any subsequent attempt, so exactly one retry backoff (InitialInterval) separates the failure from the expected redispatch. The retry policy expiration and the activity timeouts are deliberately much longer than the simulation window so that no timeout can rescue a lost retry within the test's runtime.