Optional cron schedule for Workflow. If a cron schedule is specified, the Workflow will run as a cron based on the schedule. The scheduling will be based on UTC time. The schedule for the next run only happens after the current run is completed/failed/timeout. If a RetryPolicy is also supplied, and the Workflow failed or timed out, the Workflow will be retried based on the retry policy. While the Workflow is retrying, it won't schedule its next run. If the next schedule is due while the Workflow is running (or retrying), then it will skip that schedule. Cron Workflow will not stop until it is terminated or cancelled (by returning temporal.CanceledError). https://crontab.guru/ is useful for testing your cron expressions.
If set to true, instructs the client to follow the chain of execution before returning a Workflow's result.
Workflow execution is chained if the Workflow has a cron schedule or continues-as-new or configured to retry after failure or timeout.
Specifies additional non-indexed information to attach to the Workflow Execution. The values can be anything that is serializable by DataConverter.
Controls how a Workflow Execution is retried.
By default, Workflow Executions are not retried. Do not override this behavior unless you know what you're doing. More information.
Specifies additional indexed information to attach to the Workflow Execution. More info: https://docs.temporal.io/docs/typescript/search-attributes
Values are always converted using JsonPayloadConverter, even when a custom data converter is provided.
Task queue to use for Workflow tasks. It should match a task queue specified when creating a
Worker that hosts the Workflow code.
Workflow id to use when starting.
Assign a meaningful business id. This ID can be used to ensure starting Workflows is idempotent. Workflow IDs are unique, see also workflowIdReusePolicy
Whether a Workflow can be started with a Workflow Id of a Closed Workflow.
Note: A Workflow can never be started with a Workflow Id of a Running Workflow.