Skip to main content

Interface: IScheduleActivityTaskCommandAttributes

command.v1.IScheduleActivityTaskCommandAttributes

Properties of a ScheduleActivityTaskCommandAttributes.

Implemented by​

Properties​

activityId​

• Optional activityId: null | string

ScheduleActivityTaskCommandAttributes activityId

activityType​

• Optional activityType: null | IActivityType

ScheduleActivityTaskCommandAttributes activityType

• Optional header: null | IHeader

ScheduleActivityTaskCommandAttributes header

heartbeatTimeout​

• Optional heartbeatTimeout: null | IDuration

Maximum permitted time between successful worker heartbeats.

input​

• Optional input: null | IPayloads

ScheduleActivityTaskCommandAttributes input

requestEagerExecution​

• Optional requestEagerExecution: null | boolean

Request to start the activity directly bypassing matching service and worker polling The slot for executing the activity should be reserved when setting this field to true.

retryPolicy​

• Optional retryPolicy: null | IRetryPolicy

Activities are provided by a default retry policy which is controlled through the service's dynamic configuration. Retries will be attempted until schedule_to_close_timeout has elapsed. To disable retries set retry_policy.maximum_attempts to 1.

scheduleToCloseTimeout​

• Optional scheduleToCloseTimeout: null | IDuration

Indicates how long the caller is willing to wait for activity completion. The "schedule" time is when the activity is initially scheduled, not when the most recent retry is scheduled. Limits how long retries will be attempted. Either this or start_to_close_timeout must be specified. When not specified, defaults to the workflow execution timeout.

(-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)

scheduleToStartTimeout​

• Optional scheduleToStartTimeout: null | IDuration

Limits the time an activity task can stay in a task queue before a worker picks it up. The "schedule" time is when the most recent retry is scheduled. This timeout should usually not be set: it's useful in specific scenarios like worker-specific task queues. This timeout is always non retryable, as all a retry would achieve is to put it back into the same queue. Defaults to schedule_to_close_timeout or workflow execution timeout if that is not specified. More info: https://docs.temporal.io/docs/content/what-is-a-schedule-to-start-timeout/

(-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)

startToCloseTimeout​

• Optional startToCloseTimeout: null | IDuration

Maximum time an activity is allowed to execute after being picked up by a worker. This timeout is always retryable. Either this or schedule_to_close_timeout must be specified.

(-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)

taskQueue​

• Optional taskQueue: null | ITaskQueue

ScheduleActivityTaskCommandAttributes taskQueue

useWorkflowBuildId​

• Optional useWorkflowBuildId: null | boolean

If this is set, the activity would be assigned to the Build ID of the workflow. Otherwise, Assignment rules of the activity's Task Queue will be used to determine the Build ID.