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 the 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: instead, it relies on this timeout to detect that an Activity didn't complete on time. Therefore, 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