Skip to main content

Interface: ActivityOptions

Options for non-local activity invocation inside a workflow.

Extended by​

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:

  • whether cancellation requests should be propagated from the current Workflow to the Activity; and
  • when should the Activity cancellation be reported to Workflow (i.e. at which moment should the Activity call's promise fail with an ActivityFailure, with cause set to a CancelledFailure).

Note that this setting only applies to cancellation originating from cancellation being externally requested on the Workflow itself, or from internal cancellation of the CancellationScope in which the Activity call was made. Termination of a Workflow Execution always results in cancellation of its outstanding Activity executions, regardless of those Activities' ActivityCancellationType settings.

Unlike Child Workflows and Nexus Operations, which wait for the cancellation to complete by default, an Activity call fails as soon as its cancellation is requested unless this is set to WAIT_CANCELLATION_COMPLETED.

Default​

ActivityCancellationType.TRY_CANCEL

eventGroups?​

optional eventGroups?: EventGroup[]

Experimental

Event Groups to attach to this activity. They will be reflected on the corresponding workflow history events, and may be used by tooling (UI/CLI) to group related events together. See EventGroup and createEventGroup.

Event Groups is an experimental API and may change without notice.

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

priority?​

optional priority?: Priority

Priority of this activity

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

summary?​

optional summary?: string

A fixed, single-line summary for this workflow execution that may appear in the UI/CLI. This can be in single-line Temporal markdown format.

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'

Deprecated​

Worker Versioning is now deprecated. Please use the Worker Deployment API instead: https://docs.temporal.io/worker-deployments