Skip to main content

Interface: ActivityOptions

common.ActivityOptions

Options for remote activity invocation

Properties​

activityId​

• Optional activityId: string

Identifier to use for tracking the activity in Workflow history. The activityId can be accessed by the activity function. Does not need to be unique.

Default

an incremental sequence number

allowEagerDispatch​

• Optional allowEagerDispatch: boolean

Eager dispatch is an optimization that improves the throughput and load on the server for scheduling Activities. When used, the server will hand out Activity tasks back to the Worker when it completes a Workflow task. It is available from server version 1.17 behind the system.enableActivityEagerExecution feature flag.

Eager dispatch will only be used if allowEagerDispatch is enabled (the default) and taskQueue is either omitted or the same as the current Workflow.

Default

true

cancellationType​

• Optional cancellationType: ActivityCancellationType

Determines what the SDK does when the Activity is cancelled.

  • TRY_CANCEL - Initiate a cancellation request and immediately report cancellation to the workflow.
  • WAIT_CANCELLATION_COMPLETED - Wait for activity cancellation completion. Note that activity must heartbeat to receive a cancellation notification. This can block the cancellation for a long time if activity doesn't heartbeat or chooses to ignore the cancellation request.
  • ABANDON - Do not request cancellation of the activity and immediately report cancellation to the workflow.

heartbeatTimeout​

• Optional heartbeatTimeout: Duration

Heartbeat interval. Activity must heartbeat before this interval passes after a last heartbeat or activity start.

Format

number of milliseconds or ms-formatted string

retry​

• Optional retry: RetryPolicy

RetryPolicy that define how activity is retried in case of failure. If this is not set, then the server-defined default activity retry policy will be used. To ensure zero retries, set maximum attempts to 1.

scheduleToCloseTimeout​

• Optional scheduleToCloseTimeout: Duration

Total time that a workflow is willing to wait for Activity to complete. scheduleToCloseTimeout limits the total time of an Activity's execution including retries (use startToCloseTimeout to limit the time of a single attempt).

Either this option or startToCloseTimeout is required.

Default

unlimited

Format

number of milliseconds or ms-formatted string

scheduleToStartTimeout​

• Optional scheduleToStartTimeout: Duration

Time that the Activity Task can stay in the Task Queue before it is picked up by a Worker. Do not specify this timeout unless using host specific Task Queues for Activity Tasks are being used for routing. scheduleToStartTimeout is always non-retryable. Retrying after this timeout doesn't make sense as it would just put the Activity Task back into the same Task Queue.

Default

scheduleToCloseTimeout or unlimited

Format

number of milliseconds or ms-formatted string

startToCloseTimeout​

• Optional startToCloseTimeout: Duration

Maximum time of a single Activity execution attempt. Note that the Temporal Server doesn't detect Worker process failures directly. It relies on this timeout to detect that an Activity that didn't complete on time. So this timeout should be as short as the longest possible execution of the Activity body. Potentially long running Activities must specify heartbeatTimeout and call activity.Context.heartbeat periodically for timely failure detection.

Either this option or scheduleToCloseTimeout is required.

Default

scheduleToCloseTimeout or unlimited

Format

number of milliseconds or ms-formatted string

taskQueue​

• Optional taskQueue: string

Task queue name.

Default

current worker task queue

versioningIntent​

• Optional versioningIntent: VersioningIntent

When using the Worker Versioning feature, specifies whether this Activity should run on a worker with a compatible Build Id or not. See VersioningIntent.

Default

'COMPATIBLE'

@experimental