Package io.temporal.workflow

Class ChildWorkflowOptions.Builder

  • Enclosing class:
    ChildWorkflowOptions
    public static final class ChildWorkflowOptions.Builder
extends java.lang.Object

    • Method Detail

      • setNamespace

        public ChildWorkflowOptions.Builder setNamespace​(java.lang.String namespace)
        Specify namespace in which workflow should be started.

        TODO: Resolve conflict with WorkflowClient namespace.

      • setWorkflowId

        public ChildWorkflowOptions.Builder setWorkflowId​(java.lang.String workflowId)
        Workflow id to use when starting. If not specified a UUID is generated. Note that it is dangerous as in case of client side retries no deduplication will happen based on the generated id. So prefer assigning business meaningful ids if possible.

      • setWorkflowIdReusePolicy

        public ChildWorkflowOptions.Builder setWorkflowIdReusePolicy​(io.temporal.api.enums.v1.WorkflowIdReusePolicy workflowIdReusePolicy)
        Specifies server behavior if a completed workflow with the same id exists. Note that under no conditions Temporal allows two workflows with the same namespace and workflow id run simultaneously.
        • AllowDuplicate is the default value. It allows new run independently of the previous run closure status.
        • AllowDuplicateFailedOnly means that workflow can start if previous run failed or was canceled or terminated.
        • RejectDuplicate doesn't allow new run independently of the previous run closure status.

      • setWorkflowRunTimeout

        public ChildWorkflowOptions.Builder setWorkflowRunTimeout​(java.time.Duration workflowRunTimeout)
        The time after which child workflow run is automatically terminated by Temporal service with CHILD_WORKFLOW_EXECUTION_TIMED_OUT status.
        Parent workflow receives ChildWorkflowFailure exception with TimeoutFailure cause from the child's Promise if this happens.

        When a workflow reaches Workflow Run Timeout, it can't make any progress after that. Do not rely on this timeout in workflow implementation or business logic. This timeout is not designed to be handled in workflow code to perform any logic in case of timeout. Consider using workflow timers instead.

        If you catch yourself setting this timeout to very small values, you're likely using it wrong.

        Example: If Workflow Run Timeout is 30 seconds and the network was unavailable for 1 minute, workflows that were scheduled before the network blip will never have a chance to make progress or react, and will be terminated.
        A timer that is scheduled in the workflow code using Workflow.newTimer(Duration) will handle this situation gracefully. A workflow with such a timer will start after the network blip. If it started before the network blip and the timer fires during the network blip, it will get delivered after connectivity is restored and the workflow will be able to resume.

      • setWorkflowExecutionTimeout

        public ChildWorkflowOptions.Builder setWorkflowExecutionTimeout​(java.time.Duration workflowExecutionTimeout)
        The time after which child workflow execution (which includes run retries and continue as new) is automatically terminated by Temporal service with WORKFLOW_EXECUTION_TIMED_OUT status.
        Parent workflow receives ChildWorkflowFailure exception with TimeoutFailure cause from the child's Promise if this happens.

        When a workflow reaches Workflow Execution Timeout, it can't make any progress after that. Do not rely on this timeout in workflow implementation or business logic. This timeout is not designed to be handled in workflow code to perform any logic in case of timeout. Consider using workflow timers instead.

        If you catch yourself setting this timeout to very small values, you're likely using it wrong.

        Example: If Workflow Execution Timeout is 30 seconds and the network was unavailable for 1 minute, workflows that were scheduled before the network blip will never have a chance to make progress or react, and will be terminated.
        A timer that is scheduled in the workflow code using Workflow.newTimer(Duration) will handle this situation gracefully. A workflow with such a timer will start after the network blip. If it started before the network blip and the timer fires during the network blip, it will get delivered after connectivity is restored and the workflow will be able to resume.

      • setWorkflowTaskTimeout

        public ChildWorkflowOptions.Builder setWorkflowTaskTimeout​(java.time.Duration workflowTaskTimeout)
        Maximum execution time of a single workflow task. Default is 10 seconds. Maximum accepted value is 60 seconds.

      • setTaskQueue

        public ChildWorkflowOptions.Builder setTaskQueue​(java.lang.String taskQueue)
        Task queue to use for workflow tasks. It should match a task queue specified when creating a Worker that hosts the workflow code.

      • setRetryOptions

        public ChildWorkflowOptions.Builder setRetryOptions​(RetryOptions retryOptions)
        RetryOptions that define how child workflow is retried in case of failure. Default is null which is no reties.

      • setParentClosePolicy

        public ChildWorkflowOptions.Builder setParentClosePolicy​(io.temporal.api.enums.v1.ParentClosePolicy parentClosePolicy)
        Specifies how this workflow reacts to the death of the parent workflow.

      • setMemo

        public ChildWorkflowOptions.Builder setMemo​(java.util.Map<java.lang.String,​java.lang.Object> memo)
        Specifies additional non-indexed information in result of list workflow.