Get desktop application:
View/edit binary Protocol Buffers messages
CallbackInfo contains the state of an attached workflow callback.
Used in:
Information on how this callback should be invoked (e.g. its URL and type).
Trigger for this callback.
The time when the callback was registered.
The number of attempts made to deliver the callback. This number represents a minimum bound since the attempt is incremented after the callback request completes.
The time when the last attempt completed.
The last attempt's failure, if any.
The time when the next attempt is scheduled.
If the state is BLOCKED, blocked reason provides additional information.
Used in:
Trigger for when a workflow update is completed.
Used in:
Trigger for when the workflow is closed.
Used in:
(message has no fields)
Holds information about ongoing transition of a workflow execution from one deployment to another. Deprecated. Use DeploymentVersionTransition.
Used in:
The target deployment of the transition. Null means a so-far-versioned workflow is transitioning to unversioned workers.
Holds information about ongoing transition of a workflow execution from one worker deployment version to another. Experimental. Might change in the future.
Used in:
Deprecated. Use `deployment_version`.
The target Version of the transition. If nil, a so-far-versioned workflow is transitioning to unversioned workers.
NewWorkflowExecutionInfo is a shared message that encapsulates all the required arguments to starting a workflow in different contexts.
Used in:
Serialized arguments to the workflow.
Total workflow execution timeout including retries and continue as new.
Timeout of a single workflow run.
Timeout of a single workflow task.
Default: WORKFLOW_ID_REUSE_POLICY_ALLOW_DUPLICATE.
The retry policy for the workflow. Will never exceed `workflow_execution_timeout`.
See https://docs.temporal.io/docs/content/what-is-a-temporal-cron-job/
Metadata on the workflow if it is started. This is carried over to the WorkflowExecutionConfig for use by user interfaces to display the fixed as-of-start summary and details of the workflow.
If set, takes precedence over the Versioning Behavior sent by the SDK on Workflow Task completion. To unset the override after the workflow is running, use UpdateWorkflowExecutionOptions.
Priority metadata
NexusOperationCancellationInfo contains the state of a nexus operation cancellation.
Used in:
The time when cancellation was requested.
The number of attempts made to deliver the cancel operation request. This number represents a minimum bound since the attempt is incremented after the request completes.
The time when the last attempt completed.
The last attempt's failure, if any.
The time when the next attempt is scheduled.
If the state is BLOCKED, blocked reason provides additional information.
When StartWorkflowExecution uses the conflict policy WORKFLOW_ID_CONFLICT_POLICY_USE_EXISTING and there is already an existing running workflow, OnConflictOptions defines actions to be taken on the existing running workflow. In this case, it will create a WorkflowExecutionOptionsUpdatedEvent history event in the running workflow with the changes requested in this object.
Used in:
Attaches the request ID to the running workflow.
Attaches the completion callbacks to the running workflow.
Attaches the links to the WorkflowExecutionOptionsUpdatedEvent history event.
Used in:
Absence of `assigned_build_id` generally means this task is on an "unversioned" task queue. In rare cases, it can also mean that the task queue is versioned but we failed to write activity's independently-assigned build ID to the database. This case heals automatically once the task is dispatched. Deprecated. This field should be cleaned up when versioning-2 API is removed. [cleanup-experimental-wv]
Deprecated. When present, it means this activity is assigned to the build ID of its workflow.
Deprecated. This means the activity is independently versioned and not bound to the build ID of its workflow. The activity will use the build id in this field instead. If the task fails and is scheduled again, the assigned build ID may change according to the latest versioning rules.
Deprecated. The version stamp of the worker to whom this activity was most recently dispatched This field should be cleaned up when versioning-2 API is removed. [cleanup-experimental-wv]
The time activity will wait until the next retry. If activity is currently running it will be next retry interval if activity failed. If activity is currently waiting it will be current retry interval. If there will be no retry it will be null.
The time when the last activity attempt was completed. If activity has not been completed yet then it will be null.
Next time when activity will be scheduled. If activity is currently scheduled or started it will be null.
Indicates if activity is paused.
The deployment this activity was dispatched to most recently. Present only if the activity was dispatched to a versioned worker. Deprecated. Use `last_deployment_version`.
The Worker Deployment Version this activity was dispatched to most recently. Deprecated. Use `last_deployment_version`.
The Worker Deployment Version this activity was dispatched to most recently. If nil, the activity has not yet been dispatched or was last dispatched to an unversioned worker.
Priority metadata. If this message is not present, or any fields are not present, they inherit the values from the workflow.
Current activity options. May be different from the one used to start the activity.
Used in:
The time when the activity was paused.
activity was paused by the manual intervention
activity was paused by the rule
Used in:
The identity of the actor that paused the activity.
Reason for pausing the activity.
Used in:
The rule that paused the activity.
The identity of the actor that created the rule.
Reason why rule was created. Populated from rule description.
Used in:
Default: PARENT_CLOSE_POLICY_TERMINATE.
PendingNexusOperationInfo contains the state of a pending Nexus operation.
Used in:
Endpoint name. Resolved to a URL via the cluster's endpoint registry.
Service name.
Operation name.
Operation ID. Only set for asynchronous operations after a successful StartOperation call. Deprecated. Renamed to operation_token.
Schedule-to-close timeout for this operation. This is the only timeout settable by a workflow. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)
The time when the operation was scheduled.
The number of attempts made to deliver the start operation request. This number is approximate, it is incremented when a task is added to the history queue. In practice, there could be more attempts if a task is executed but fails to commit, or less attempts if a task was never executed.
The time when the last attempt completed.
The last attempt's failure, if any.
The time when the next attempt is scheduled.
The event ID of the NexusOperationScheduled event. Can be used to correlate an operation in the DescribeWorkflowExecution response with workflow history.
If the state is BLOCKED, blocked reason provides additional information.
Operation token. Only set for asynchronous operations after a successful StartOperation call.
Schedule-to-start timeout for this operation. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)
Start-to-close timeout for this operation. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)
Used in:
original_scheduled_time is the scheduled time of the first workflow task during workflow task heartbeat. Heartbeat workflow task is done by RespondWorkflowTaskComplete with ForceCreateNewWorkflowTask == true and no command In this case, OriginalScheduledTime won't change. Then when current time - original_scheduled_time exceeds some threshold, the workflow task will be forced timeout.
PostResetOperation represents an operation to be performed on the new workflow execution after a workflow reset.
Used in: ,
SignalWorkflow represents sending a signal after a workflow reset. Keep the parameter in sync with temporal.api.workflowservice.v1.SignalWorkflowExecutionRequest.
Used in:
The workflow author-defined name of the signal to send to the workflow.
Serialized value(s) to provide with the signal.
Headers that are passed with the signal to the processing workflow.
Links to be associated with the WorkflowExecutionSignaled event.
UpdateWorkflowOptions represents updating workflow execution options after a workflow reset. Keep the parameters in sync with temporal.api.workflowservice.v1.UpdateWorkflowExecutionOptionsRequest.
Used in:
Update Workflow options that were originally specified via StartWorkflowExecution. Partial updates are accepted and controlled by update_mask.
Controls which fields from `workflow_execution_options` will be applied. To unset a field, set it to null and use the update mask to indicate that it should be mutated.
RequestIdInfo contains details of a request ID.
Used in:
The event type of the history event generated by the request.
The event id of the history event generated by the request. It's possible the event ID is not known (unflushed buffered event). In this case, the value will be zero or a negative value, representing an invalid ID.
Indicate if the request is still buffered. If so, the event ID is not known and its value will be an invalid event ID.
ResetPointInfo records the workflow event id that is the first one processed by a given build id or binary checksum. A new reset point will be created if either build id or binary checksum changes (although in general only one or the other will be used at a time).
Used in:
Worker build id.
Deprecated. A worker binary version identifier.
The first run ID in the execution chain that was touched by this worker build.
Event ID of the first WorkflowTaskCompleted event processed by this worker build.
(-- api-linter: core::0214::resource-expiry=disabled aip.dev/not-precedent: TTL is not defined for ResetPointInfo. --) The time that the run is deleted due to retention.
false if the reset point has pending childWFs/reqCancels/signalExternals.
Used in: ,
Used to override the versioning behavior (and pinned deployment version, if applicable) of a specific workflow execution. If set, this override takes precedence over worker-sent values. See `WorkflowExecutionInfo.VersioningInfo` for more information. To remove the override, call `UpdateWorkflowExecutionOptions` with a null `VersioningOverride`, and use the `update_mask` to indicate that it should be mutated. Pinned behavior overrides are automatically inherited by child workflows, workflow retries, continue-as-new workflows, and cron workflows.
Used in: , , , , , ,
Indicates whether to override the workflow to be AutoUpgrade or Pinned.
Override the workflow to have Pinned behavior.
Override the workflow to have AutoUpgrade behavior.
Required. Deprecated. Use `override`.
Required if behavior is `PINNED`. Must be null if behavior is `AUTO_UPGRADE`. Identifies the worker deployment to pin the workflow to. Deprecated. Use `override.pinned.version`.
Required if behavior is `PINNED`. Must be absent if behavior is not `PINNED`. Identifies the worker deployment version to pin the workflow to, in the format "<deployment_name>.<build_id>". Deprecated. Use `override.pinned.version`.
Used in:
Defaults to PINNED_OVERRIDE_BEHAVIOR_UNSPECIFIED. See `PinnedOverrideBehavior` for details.
Specifies the Worker Deployment Version to pin this workflow to. Required if the target workflow is not already pinned to a version. If omitted and the target workflow is already pinned, the effective pinned version will be the existing pinned version. If omitted and the target workflow is not pinned, the override request will be rejected with a PreconditionFailed error.
Used in:
Unspecified.
Override workflow behavior to be Pinned.
Used in:
User metadata provided on start workflow.
Holds all the extra information about workflow execution that is not part of Visibility.
Used in:
Workflow execution expiration time is defined as workflow start time plus expiration timeout. Workflow start time may change after workflow reset.
Workflow run expiration time is defined as current workflow run start time plus workflow run timeout.
indicates if the workflow received a cancel request
Last workflow reset time. Nil if the workflow was never reset.
Original workflow start time.
Reset Run ID points to the new run when this execution is reset. If the execution is reset multiple times, it points to the latest run.
Request ID information (eg: history event information associated with the request ID). Note: It only contains request IDs from StartWorkflowExecution requests, including indirect calls (eg: if SignalWithStartWorkflowExecution starts a new workflow, then the request ID is used in the StartWorkflowExecution request).
Information about the workflow execution pause operation.
Hold basic information about a workflow execution. This structure is a part of visibility, and thus contain a limited subset of information.
Used in: , , , , ,
If set, the most recent worker version stamp that appeared in a workflow task completion Deprecated. This field should be cleaned up when versioning-2 API is removed. [cleanup-experimental-wv]
Workflow execution duration is defined as difference between close time and execution time. This field is only populated if the workflow is closed.
Contains information about the root workflow execution. The root workflow execution is defined as follows: 1. A workflow without parent workflow is its own root workflow. 2. A workflow that has a parent workflow has the same root workflow as its parent workflow. Note: workflows continued as new or reseted may or may not have parents, check examples below. Examples: Scenario 1: Workflow W1 starts child workflow W2, and W2 starts child workflow W3. - The root workflow of all three workflows is W1. Scenario 2: Workflow W1 starts child workflow W2, and W2 continued as new W3. - The root workflow of all three workflows is W1. Scenario 3: Workflow W1 continued as new W2. - The root workflow of W1 is W1 and the root workflow of W2 is W2. Scenario 4: Workflow W1 starts child workflow W2, and W2 is reseted, creating W3 - The root workflow of all three workflows is W1. Scenario 5: Workflow W1 is reseted, creating W2. - The root workflow of W1 is W1 and the root workflow of W2 is W2.
The currently assigned build ID for this execution. Presence of this value means worker versioning is used for this execution. Assigned build ID is selected based on Worker Versioning Assignment Rules when the first workflow task of the execution is scheduled. If the first workflow task fails and is scheduled again, the assigned build ID may change according to the latest versioning rules. Assigned build ID can also change in the middle of a execution if Compatible Redirect Rules are applied to this execution. Deprecated. This field should be cleaned up when versioning-2 API is removed. [cleanup-experimental-wv]
Build ID inherited from a previous/parent execution. If present, assigned_build_id will be set to this, instead of using the assignment rules. Deprecated. This field should be cleaned up when versioning-2 API is removed. [cleanup-experimental-wv]
The first run ID in the execution chain. Executions created via the following operations are considered to be in the same chain - ContinueAsNew - Workflow Retry - Workflow Reset - Cron Schedule
Absent value means the workflow execution is not versioned. When present, the execution might be versioned or unversioned, depending on `versioning_info.behavior` and `versioning_info.versioning_override`. Experimental. Versioning info is experimental and might change in the future.
The name of Worker Deployment that completed the most recent workflow task.
Priority metadata
Total size in bytes of all external payloads referenced in workflow history.
Count of external payloads referenced in workflow history.
Used in: , , ,
If set, takes precedence over the Versioning Behavior sent by the SDK on Workflow Task completion.
If set, overrides the workflow's priority sent by the SDK.
The time-skipping configuration for this workflow execution. When `fast_forward` is set, time will be fast-forwarded to a future point relative to the current workflow timestamp. Each call takes effect, even if `fast_forward` is set to the same duration, since the target time is recalculated from the current timestamp on every call. This field must be updated as a whole; updating individual sub-fields is not supported. When setting the update mask in `UpdateWorkflowExecutionOptionsRequest`, `BatchOperationUpdateWorkflowExecutionOptions`, etc., use a mask that covers the entire field.
WorkflowExecutionPauseInfo contains the information about a workflow execution pause.
Used in:
The identity of the client who paused the workflow execution.
The time when the workflow execution was paused.
The reason for pausing the workflow execution.
Holds all the information about worker versioning for a particular workflow execution. Experimental. Versioning info is experimental and might change in the future.
Used in:
Versioning behavior determines how the server should treat this execution when workers are upgraded. When present it means this workflow execution is versioned; UNSPECIFIED means unversioned. See the comments in `VersioningBehavior` enum for more info about different behaviors. Child workflows or CaN executions **inherit** their parent/previous run's effective Versioning Behavior and Version (except when the new execution runs on a task queue not belonging to the same deployment version as the parent/previous run's task queue). The first workflow task will be dispatched according to the inherited behavior (or to the current version of the task-queue's deployment in the case of AutoUpgrade.) After completion of their first workflow task the Deployment Version and Behavior of the execution will update according to configuration on the worker. Note that `behavior` is overridden by `versioning_override` if the latter is present.
The worker deployment that completed the last workflow task of this workflow execution. Must be present if `behavior` is set. Absent value means no workflow task is completed, or the last workflow task was completed by an unversioned worker. Unversioned workers may still send a deployment value which will be stored here, so the right way to check if an execution is versioned if an execution is versioned or not is via the `behavior` field. Note that `deployment` is overridden by `versioning_override` if the latter is present. Deprecated. Use `deployment_version`.
Deprecated. Use `deployment_version`.
The Worker Deployment Version that completed the last workflow task of this workflow execution. An absent value means no workflow task is completed, or the workflow is unversioned. If present, and `behavior` is UNSPECIFIED, the last task of this workflow execution was completed by a worker that is not using versioning but _is_ passing Deployment Name and Build ID. Child workflows or CaN executions **inherit** their parent/previous run's effective Versioning Behavior and Version (except when the new execution runs on a task queue not belonging to the same deployment version as the parent/previous run's task queue). The first workflow task will be dispatched according to the inherited behavior (or to the current version of the task-queue's deployment in the case of AutoUpgrade.) After completion of their first workflow task the Deployment Version and Behavior of the execution will update according to configuration on the worker. Note that if `versioning_override.behavior` is PINNED then `versioning_override.pinned_version` will override this value.
Present if user has set an execution-specific versioning override. This override takes precedence over SDK-sent `behavior` (and `version` when override is PINNED). An override can be set when starting a new execution, as well as afterwards by calling the `UpdateWorkflowExecutionOptions` API. Pinned overrides are automatically inherited by child workflows, continue-as-new workflows, workflow retries, and cron workflows.
When present, indicates the workflow is transitioning to a different deployment. Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current deployment if the task queue's current deployment is different from the workflow's deployment. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current deployment. As soon as a poller from that deployment is available to receive the task, the workflow will automatically start a transition to that deployment and continue execution there. A deployment transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target deployment, the transition completes and the workflow's `deployment` and `behavior` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new deployment. Deprecated. Use version_transition.
When present, indicates the workflow is transitioning to a different deployment version (which may belong to the same deployment name or another). Can indicate one of the following transitions: unversioned -> versioned, versioned -> versioned on a different deployment version, or versioned -> unversioned. Not applicable to workflows with PINNED behavior. When a workflow with AUTO_UPGRADE behavior creates a new workflow task, it will automatically start a transition to the task queue's current version if the task queue's current version is different from the workflow's current deployment version. If the AUTO_UPGRADE workflow is stuck due to backlogged activity or workflow tasks, those tasks will be redirected to the task queue's current version. As soon as a poller from that deployment version is available to receive the task, the workflow will automatically start a transition to that version and continue execution there. A version transition can only exist while there is a pending or started workflow task. Once the pending workflow task completes on the transition's target version, the transition completes and the workflow's `behavior`, and `deployment_version` fields are updated per the worker's task completion response. Pending activities will not start new attempts during a transition. Once the transition is completed, pending activities will start their next attempt on the new version.
Monotonic counter reflecting the latest routing decision for this workflow execution. Used for staleness detection between history and matching when dispatching tasks to workers. Incremented when a workflow execution routes to a new deployment version, which happens when a worker of the new deployment version completes a workflow task. Note: Pinned tasks and sticky tasks send a value of 0 for this field since these tasks do not face the problem of inconsistent dispatching that arises from eventual consistency between task queues and their partitions.
Experimental. If this workflow is the result of a continue-as-new, this field is set to the initial_versioning_behavior specified in that command. Only used for the initial task of this run and the initial task of any retries of this run. Not passed to children or to future continue-as-new. Note: In the first release of Upgrade-on-CaN, when the only ContinueAsNewVersioningBehavior was AutoUpgrade, a non-empty InheritedAutoUpgradeInfo meant that the workflow should start as AutoUpgrade. So for compatibility with ContinueAsNew history commands generated during that time, know that an UNSPECIFIED value here is equivalent to ContinueAsNewVersioningBehaviorAutoUpgrade if the behavior of the workflow is AutoUpgrade.