Get desktop application:
View/edit binary Protocol Buffers messages
Used in:
The same timer id from the start timer command
Used in:
Used in:
Metadata on the command. This is sometimes carried over to the history event if one is created as a result of the command. Most commands won't have this information, and how this information is used is dependent upon the interface that reads it. Current well-known uses: * start_child_workflow_execution_command_attributes - populates temporal.api.workflow.v1.WorkflowExecutionInfo.user_metadata where the summary and details are used by user interfaces to show fixed as-of-start workflow summary and details. * start_timer_command_attributes - populates temporal.api.history.v1.HistoryEvent for timer started where the summary is used to identify the timer.
Event Group Markers attached to the command by the workflow author.
The command details. The type must match that in `command_type`.
16 is available for use - it was used as part of a prototype that never made it into a release
Used in:
Used in:
Timeout of a single workflow run.
Timeout of a single workflow task.
How long the workflow start will be delayed - not really a "backoff" in the traditional sense.
Should be removed
Should be removed
Should be removed
Should be removed. Not necessarily unused but unclear and not exposed by SDKs.
If this is set, the new execution inherits the Build ID of the current execution. Otherwise, the assignment rules will be used to independently assign a Build ID to the new execution. Deprecated. Only considered for versioning v0.2.
Experimental. Optionally decide the versioning behavior that the first task of the new run should use. For example, choose to AutoUpgrade on continue-as-new instead of inheriting the pinned version of the previous run.
Used in:
Used in:
If set, update the workflow memo with the provided values. The values will be merged with the existing memo. If the user wants to delete values, a default/empty Payload should be used as the value for the key being deleted.
Used in:
The message ID of the message to which this command is a pointer.
Used in:
Used in:
The `ACTIVITY_TASK_SCHEDULED` event id for the activity being cancelled.
Used in:
Deprecated. Cross-namespace operations are disabled by default as of server 1.30.1.
Deprecated.
Set this to true if the workflow being cancelled is a child of the workflow originating this command. The request will be rejected if it is set to true and the target workflow is *not* a child of the requesting workflow.
Reason for requesting the cancellation
Used in:
The `NEXUS_OPERATION_SCHEDULED` event ID (a unique identifier) for the operation to be canceled. The operation may ignore cancellation and end up with any completion state.
Used in:
Indicates how long the caller is willing to wait for activity completion. The "schedule" time is when the activity is initially scheduled, not when the most recent retry is scheduled. Limits how long retries will be attempted. Either this or `start_to_close_timeout` must be specified. When not specified, defaults to the workflow execution timeout. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)
Limits the time an activity task can stay in a task queue before a worker picks it up. The "schedule" time is when the most recent retry is scheduled. This timeout should usually not be set: it's useful in specific scenarios like worker-specific task queues. This timeout is always non retryable, as all a retry would achieve is to put it back into the same queue. Defaults to `schedule_to_close_timeout` or workflow execution timeout if that is not specified. More info: https://docs.temporal.io/docs/content/what-is-a-schedule-to-start-timeout/ (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)
Maximum time an activity is allowed to execute after being picked up by a worker. This timeout is always retryable. Either this or `schedule_to_close_timeout` must be specified. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)
Maximum permitted time between successful worker heartbeats.
Activities are provided by a default retry policy which is controlled through the service's dynamic configuration. Retries will be attempted until `schedule_to_close_timeout` has elapsed. To disable retries set retry_policy.maximum_attempts to 1.
Request to start the activity directly bypassing matching service and worker polling The slot for executing the activity should be reserved when setting this field to true.
If this is set, the activity would be assigned to the Build ID of the workflow. Otherwise, Assignment rules of the activity's Task Queue will be used to determine the Build ID.
Priority metadata. If this message is not present, or any fields are not present, they inherit the values from the workflow.
Used in:
Endpoint name, must exist in the endpoint registry or this command will fail.
Service name.
Operation name.
Input for the operation. The server converts this into Nexus request content and the appropriate content headers internally when sending the StartOperation request. On the handler side, if it is also backed by Temporal, the content is transformed back to the original Payload sent in this command.
Schedule-to-close timeout for this operation. Indicates how long the caller is willing to wait for operation completion. Calls are retried internally by the server. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)
Header to attach to the Nexus request. Users are responsible for encrypting sensitive data in this header as it is stored in workflow history and transmitted to external services as-is. This is useful for propagating tracing information. Note these headers are not the same as Temporal headers on internal activities and child workflows, these are transmitted to Nexus operations that may be external and are not traditional payloads.
Schedule-to-start timeout for this operation. Indicates how long the caller is willing to wait for the operation to be started (or completed if synchronous) by the handler. If the operation is not started within this timeout, it will fail with TIMEOUT_TYPE_SCHEDULE_TO_START. If not set or zero, no schedule-to-start timeout is enforced. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --) Requires server version 1.31.0 or later.
Start-to-close timeout for this operation. Indicates how long the caller is willing to wait for an asynchronous operation to complete after it has been started. If the operation does not complete within this timeout after starting, it will fail with TIMEOUT_TYPE_START_TO_CLOSE. Only applies to asynchronous operations. Synchronous operations ignore this timeout. If not set or zero, no start-to-close timeout is enforced. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --) Requires server version 1.31.0 or later.
Used in:
Deprecated. Cross-namespace operations are disabled by default as of server 1.30.1.
The workflow author-defined name of the signal to send to the workflow.
Serialized value(s) to provide with the signal.
Deprecated
Set this to true if the workflow being cancelled is a child of the workflow originating this command. The request will be rejected if it is set to true and the target workflow is *not* a child of the requesting workflow.
Headers that are passed by the workflow that is sending a signal to the external workflow that is receiving this signal.
Used in:
Deprecated. Cross-namespace operations are disabled by default as of server 1.30.1.
Total workflow execution timeout including retries and continue as new.
Timeout of a single workflow run.
Timeout of a single workflow task.
Default: PARENT_CLOSE_POLICY_TERMINATE.
Default: WORKFLOW_ID_REUSE_POLICY_ALLOW_DUPLICATE.
Establish a cron schedule for the child workflow.
If this is set, the child workflow inherits the Build ID of the parent. Otherwise, the assignment rules of the child's Task Queue will be used to independently assign a Build ID to it. Deprecated. Only considered for versioning v0.2.
Priority metadata. If this message is not present, or any fields are not present, they inherit the values from the workflow.
Used in:
An id for the timer, currently live timers must have different ids. Typically autogenerated by the SDK.
How long until the timer fires, producing a `TIMER_FIRED` event. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)
Used in: