Builds ActivityStub

Allows to specify options directly on the java SDK's ActivityOptions. Use it in case an appropriate withXXX method is missing

In case of an activity's scope cancellation the corresponding activity stub call fails with a zio.temporal.failure.CanceledFailure

Note:
This method has extremely limited usage. The majority of users should just set zio.temporal.workflow.ZWorkflowClientOptions.withContextPropagators

Both "client" (workflow worker) and "server" (activity worker) sides of context propagation from a workflow to an activity exist in a worker process (potentially the same one), so they typically share the same worker options. Specifically, ContextPropagators specified on zio.temporal.workflow.ZWorkflowClientOptions.withContextPropagators.

zio.temporal.workflow.ZWorkflowClientOptions.withContextPropagators is the right place to specify ContextPropagators between Workflow and an Activity.
Specifying context propagators with this method overrides them only on the "client" (workflow) side and can't be automatically promoted to the "server" (activity worker), which always uses ContextPropagators from zio.temporal.workflow.ZWorkflowClientOptions.contextPropagators
The only legitimate usecase for this method is probably a situation when the specific activity is implemented in a different language and in a completely different worker codebase and in that case setting a ContextPropagator that is applied only on a "client" side could make sense.
This is also why there is no equivalent method on Local activity options.

If set to true, will not request eager execution regardless of worker settings. If false, eager execution may still be disabled at the worker level or eager execution may not be requested due to lack of available slots.

Eager activity execution means the server returns requested eager activities directly from the workflow task back to this worker which is faster than non-eager which may be dispatched to a separate worker.

Defaults to false, meaning that eager activity execution will be requested if possible.

Heartbeat interval. Activity must call ZActivityExecutionContext.heartbeat before this interval passes after the last heartbeat or the Activity starts.

RetryOptions that define how an Activity is retried in case of failure.

If not provided, the server-defined default activity retry policy will be used. If not overridden, the server default activity retry policy is:

 InitialInterval: 1 second BackoffCoefficient: 2 MaximumInterval: 100 seconds // 100 * InitialInterval
MaximumAttempts: 0 // Unlimited NonRetryableErrorTypes: [] 

Total time that a workflow is willing to wait for an Activity to complete.

ScheduleToCloseTimeout limits the total time of an Activity's execution including retries withStartToCloseTimeout to limit the time of a single attempt).

Either this option or withStartToCloseTimeout is required.

Defaults to unlimited, which is chosen if set to null.

Time that the Activity Task can stay in the Task Queue before it is picked up by a Worker.

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.

Defaults to unlimited.

Maximum time of a single Activity 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 ZActivityExecutionContext.heartbeat periodically for timely failure detection.

If withScheduleToCloseTimeout is not provided, then this timeout is required.

Task queue to use when dispatching activity task to a worker. By default, it is the same task list name the workflow was started with.

Specifies whether this activity should run on a worker with a compatible Build Id or not.