Get desktop application:
View/edit binary Protocol Buffers messages
Used in:
The id of the `ACTIVITY_TASK_SCHEDULED` event this modification corresponds to.
If set, update the retry policy of the activity, replacing it with the specified one. The number of attempts at the activity is preserved.
Used in:
The id of the `ACTIVITY_TASK_SCHEDULED` event this cancel request corresponds to
The `WORKFLOW_TASK_COMPLETED` event which this command was reported with
Used in:
Additional information that the activity reported upon confirming cancellation
id of the most recent `ACTIVITY_TASK_CANCEL_REQUESTED` event which refers to the same activity
The id of the `ACTIVITY_TASK_SCHEDULED` event this cancel confirmation corresponds to
The id of the `ACTIVITY_TASK_STARTED` event this cancel confirmation corresponds to
id of the worker who canceled this activity
Version info of the worker who processed this workflow task. Deprecated. This field should be cleaned up when versioning-2 API is removed. [cleanup-experimental-wv]
Used in:
Serialized results of the activity. IE: The return value of the activity function
The id of the `ACTIVITY_TASK_SCHEDULED` event this completion corresponds to
The id of the `ACTIVITY_TASK_STARTED` event this completion corresponds to
id of the worker that completed this task
Version info of the worker who processed this workflow task. Deprecated. This field should be cleaned up when versioning-2 API is removed. [cleanup-experimental-wv]
Used in:
Failure details
The id of the `ACTIVITY_TASK_SCHEDULED` event this failure corresponds to
The id of the `ACTIVITY_TASK_STARTED` event this failure corresponds to
id of the worker that failed this task
Version info of the worker who processed this workflow task. Deprecated. This field should be cleaned up when versioning-2 API is removed. [cleanup-experimental-wv]
Used in:
The worker/user assigned identifier for the activity
Indicates how long the caller is willing to wait for an activity completion. Limits how long retries will be attempted. Either this or `start_to_close_timeout` must be specified. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)
Limits time an activity task can stay in a task queue before a worker picks it up. 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 not specified. (-- 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.
The `WORKFLOW_TASK_COMPLETED` event which this command was reported with
Activities are assigned a default retry policy controlled by the service's dynamic configuration. Retries will happen up to `schedule_to_close_timeout`. To disable retries set retry_policy.maximum_attempts to 1.
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. Deprecated. This field should be cleaned up when versioning-2 API is removed. [cleanup-experimental-wv]
Priority metadata. If this message is not present, or any fields are not present, they inherit the values from the workflow.
Used in:
The id of the `ACTIVITY_TASK_SCHEDULED` event this task corresponds to
id of the worker that picked up this task
This field is populated from the RecordActivityTaskStartedRequest. Matching service would set the request_id on the RecordActivityTaskStartedRequest to a new UUID. This is useful in case a RecordActivityTaskStarted call succeed but matching doesn't get that response, so matching could retry and history service would return success if the request_id matches. In that case, matching will continue to deliver the task to worker. Without this field, history service would return AlreadyStarted error, and matching would drop the task.
Starting at 1, the number of times this task has been attempted
Will be set to the most recent failure details, if this task has previously failed and then been retried.
Version info of the worker to whom this task was dispatched. Deprecated. This field should be cleaned up when versioning-2 API is removed. [cleanup-experimental-wv]
Used by server internally to properly reapply build ID redirects to an execution when rebuilding it from events. Deprecated. This field should be cleaned up when versioning-2 API is removed. [cleanup-experimental-wv]
Used in:
If this activity had failed, was retried, and then timed out, that failure is stored as the `cause` in here.
The id of the `ACTIVITY_TASK_SCHEDULED` event this timeout corresponds to
The id of the `ACTIVITY_TASK_STARTED` event this timeout corresponds to
Used in:
Namespace of the child workflow. SDKs and UI tools should use `namespace` field but server must use `namespace_id` only.
Id of the `START_CHILD_WORKFLOW_EXECUTION_INITIATED` event which this event corresponds to
Id of the `CHILD_WORKFLOW_EXECUTION_STARTED` event which this event corresponds to
Used in:
Namespace of the child workflow. SDKs and UI tools should use `namespace` field but server must use `namespace_id` only.
Id of the `START_CHILD_WORKFLOW_EXECUTION_INITIATED` event which this event corresponds to
Id of the `CHILD_WORKFLOW_EXECUTION_STARTED` event which this event corresponds to
Used in:
Namespace of the child workflow. SDKs and UI tools should use `namespace` field but server must use `namespace_id` only.
Id of the `START_CHILD_WORKFLOW_EXECUTION_INITIATED` event which this event corresponds to
Id of the `CHILD_WORKFLOW_EXECUTION_STARTED` event which this event corresponds to
Used in:
Namespace of the child workflow. SDKs and UI tools should use `namespace` field but server must use `namespace_id` only.
Id of the `START_CHILD_WORKFLOW_EXECUTION_INITIATED` event which this event corresponds to
Used in:
Namespace of the child workflow. SDKs and UI tools should use `namespace` field but server must use `namespace_id` only.
Id of the `START_CHILD_WORKFLOW_EXECUTION_INITIATED` event which this event corresponds to
Id of the `CHILD_WORKFLOW_EXECUTION_STARTED` event which this event corresponds to
Used in:
Namespace of the child workflow. SDKs and UI tools should use `namespace` field but server must use `namespace_id` only.
Id of the `START_CHILD_WORKFLOW_EXECUTION_INITIATED` event which this event corresponds to
Id of the `CHILD_WORKFLOW_EXECUTION_STARTED` event which this event corresponds to
Wrapper for a target deployment version that the SDK declined to upgrade to. See declined_target_version_upgrade on WorkflowExecutionStartedEventAttributes.
Used in:
Revision number of the task queue routing config at the time the target was declined. If an incoming target's revision is <= this value, it is not newer and is not used for deciding whether or not to suppress the upgrade signal.
Used in:
id of the `REQUEST_CANCEL_EXTERNAL_WORKFLOW_EXECUTION_INITIATED` event this event corresponds to
Namespace of the to-be-cancelled workflow. SDKs and UI tools should use `namespace` field but server must use `namespace_id` only.
Used in:
id of the `SIGNAL_EXTERNAL_WORKFLOW_EXECUTION_INITIATED` event this event corresponds to
Namespace of the workflow which was signaled. SDKs and UI tools should use `namespace` field but server must use `namespace_id` only.
Deprecated.
Used in: , , ,
History events are the method by which Temporal SDKs advance (or recreate) workflow state. See the `EventType` enum for more info about what each event is for.
Used in:
Monotonically increasing event number, starts at 1.
Failover version of the event, used by the server for multi-cluster replication and history versioning. SDKs generally ignore this field.
Identifier used by the service to order replication and transfer tasks associated with this event. SDKs generally ignore this field.
Set to true when the SDK may ignore the event as it does not impact workflow state or information in any way that the SDK need be concerned with. If an SDK encounters an event type which it does not understand, it must error unless this is true. If it is true, it's acceptable for the event type and/or attributes to be uninterpretable.
Metadata on the event. This is often carried over from commands and client calls. Most events won't have this information, and how this information is used is dependent upon the interface that reads it. Current well-known uses: * workflow_execution_started_event_attributes - summary and details from start workflow. * timer_started_event_attributes - summary represents an identifier for the timer for use by user interfaces.
Links to related entities, such as the entity that started this event's workflow.
Server-computed authenticated caller identity associated with this event.
Event group markers attached to this event.
The event details. The type must match that in `event_type`.
Used in:
Workers use this to identify the "types" of various markers. Ex: Local activity, side effect.
Serialized information recorded in the marker
The `WORKFLOW_TASK_COMPLETED` event which this command was reported with
Some uses of markers, like a local activity, could "fail". If they did that is recorded here.
Used in:
The ID of the `NEXUS_OPERATION_CANCEL_REQUESTED` event.
The `WORKFLOW_TASK_COMPLETED` event that the corresponding RequestCancelNexusOperation command was reported with.
The id of the `NEXUS_OPERATION_SCHEDULED` event this cancel request corresponds to.
Used in:
The ID of the `NEXUS_OPERATION_CANCEL_REQUESTED` event.
The `WORKFLOW_TASK_COMPLETED` event that the corresponding RequestCancelNexusOperation command was reported with.
Failure details. A NexusOperationFailureInfo wrapping a CanceledFailureInfo.
The id of the `NEXUS_OPERATION_SCHEDULED` event this cancel request corresponds to.
Used in:
The id of the `NEXUS_OPERATION_SCHEDULED` event this cancel request corresponds to.
The `WORKFLOW_TASK_COMPLETED` event that the corresponding RequestCancelNexusOperation command was reported with.
Nexus operation completed as canceled. May or may not have been due to a cancellation request by the workflow.
Used in:
The ID of the `NEXUS_OPERATION_SCHEDULED` event. Uniquely identifies this operation.
Cancellation details.
The request ID allocated at schedule time.
Nexus operation completed successfully.
Used in:
The ID of the `NEXUS_OPERATION_SCHEDULED` event. Uniquely identifies this operation.
Serialized result of the Nexus operation. The response of the Nexus handler. Delivered either via a completion callback or as a response to a synchronous operation.
The request ID allocated at schedule time.
Nexus operation failed.
Used in:
The ID of the `NEXUS_OPERATION_SCHEDULED` event. Uniquely identifies this operation.
Failure details. A NexusOperationFailureInfo wrapping an ApplicationFailureInfo.
The request ID allocated at schedule time.
Event marking that an operation was scheduled by a workflow via the ScheduleNexusOperation command.
Used in:
Endpoint name, must exist in the endpoint registry.
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 stored in this event.
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. --) (-- api-linter: core::0142::time-field-names=disabled aip.dev/not-precedent: "timeout" is an acceptable suffix for duration fields in this API. --)
Header to attach to the Nexus request. 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.
The `WORKFLOW_TASK_COMPLETED` event that the corresponding ScheduleNexusOperation command was reported with.
A unique ID generated by the history service upon creation of this event. The ID will be transmitted with all nexus StartOperation requests and is used as an idempotentency key.
Endpoint ID as resolved in the endpoint registry at the time this event was generated. This is stored on the event and used internally by the server in case the endpoint is renamed from the time the event was originally scheduled.
Schedule-to-start timeout for this operation. See ScheduleNexusOperationCommandAttributes.schedule_to_start_timeout for details. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)
Start-to-close timeout for this operation. See ScheduleNexusOperationCommandAttributes.start_to_close_timeout for details. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)
Event marking an asynchronous operation was started by the responding Nexus handler. If the operation completes synchronously, this event is not generated. In rare situations, such as request timeouts, the service may fail to record the actual start time and will fabricate this event upon receiving the operation completion via callback.
Used in:
The ID of the `NEXUS_OPERATION_SCHEDULED` event this task corresponds to.
The operation ID returned by the Nexus handler in the response to the StartOperation request. This ID is used when canceling the operation. Deprecated: Renamed to operation_token.
The request ID allocated at schedule time.
The operation token returned by the Nexus handler in the response to the StartOperation request. This token is used when canceling the operation.
Nexus operation timed out.
Used in:
The ID of the `NEXUS_OPERATION_SCHEDULED` event. Uniquely identifies this operation.
Failure details. A NexusOperationFailureInfo wrapping a CanceledFailureInfo.
The request ID allocated at schedule time.
Used in:
The `WORKFLOW_TASK_COMPLETED` event which this command was reported with
Namespace of the workflow which failed to cancel. SDKs and UI tools should use `namespace` field but server must use `namespace_id` only.
id of the `REQUEST_CANCEL_EXTERNAL_WORKFLOW_EXECUTION_INITIATED` event this failure corresponds to
Deprecated.
Used in:
The `WORKFLOW_TASK_COMPLETED` event which this command was reported with
The namespace the workflow to be cancelled lives in. SDKs and UI tools should use `namespace` field but server must use `namespace_id` only.
Deprecated.
Workers are expected to set this to true if the workflow they are requesting to cancel is a child of the workflow which issued the request
Reason for requesting the cancellation
Used in:
The `WORKFLOW_TASK_COMPLETED` event which this command was reported with
Namespace of the workflow which failed the signal. SDKs and UI tools should use `namespace` field but server must use `namespace_id` only.
Deprecated.
Used in:
The `WORKFLOW_TASK_COMPLETED` event which this command was reported with
Namespace of the to-be-signalled workflow. SDKs and UI tools should use `namespace` field but server must use `namespace_id` only.
name/type of the signal to fire in the external workflow
Serialized arguments to provide to the signal handler
Deprecated.
Workers are expected to set this to true if the workflow they are requesting to cancel is a child of the workflow which issued the request
Used in:
Namespace of the child workflow. SDKs and UI tools should use `namespace` field but server must use `namespace_id` only.
Deprecated.
Id of the `START_CHILD_WORKFLOW_EXECUTION_INITIATED` event which this event corresponds to
The `WORKFLOW_TASK_COMPLETED` event which this command was reported with
Used in:
Namespace of the child workflow. SDKs and UI tools should use `namespace` field but server must use `namespace_id` only.
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.
Deprecated.
The `WORKFLOW_TASK_COMPLETED` event which this command was reported with
Default: WORKFLOW_ID_REUSE_POLICY_ALLOW_DUPLICATE.
If this child runs on a cron schedule, it will appear here
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
The propagated time-skipping configuration for the child workflow.
The time-skipping state propagated from the parent workflow. This can be nil if no time skipping has occurred or there is no previous run.
Used in:
Will match the `timer_id` from `TIMER_STARTED` event for this timer
The id of the `TIMER_STARTED` event itself
The `WORKFLOW_TASK_COMPLETED` event which this command was reported with
The id of the worker who requested this cancel
Used in:
Will match the `timer_id` from `TIMER_STARTED` event for this timer
The id of the `TIMER_STARTED` event itself
Used in:
The worker/user assigned id for this timer
How long until this timer fires (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)
The `WORKFLOW_TASK_COMPLETED` event which this command was reported with
Used in:
The `WORKFLOW_TASK_COMPLETED` event which this command was reported with
Used in:
User provided reason for requesting cancellation
The ID of the `REQUEST_CANCEL_EXTERNAL_WORKFLOW_EXECUTION_INITIATED` event in the external workflow history when the cancellation was requested by another workflow.
id of the worker or client who requested this cancel
Used in:
The `WORKFLOW_TASK_COMPLETED` event which this command was reported with
Used in:
Serialized result of workflow completion (ie: The return value of the workflow function)
The `WORKFLOW_TASK_COMPLETED` event which this command was reported with
If another run is started by cron, this contains the new run id.
Used in:
The run ID of the new workflow started by this continue-as-new
Timeout of a single workflow run.
Timeout of a single workflow task.
The `WORKFLOW_TASK_COMPLETED` event which this command was reported with
How long the server will wait before scheduling the first workflow task for the new run. Used for cron, retry, and other continue-as-new cases that server may enforce some minimal delay between new runs for system protection purpose.
Deprecated. If a workflow's retry policy would cause a new run to start when the current one has failed, this field would be populated with that failure. Now (when supported by server and sdk) the final event will be `WORKFLOW_EXECUTION_FAILED` with `new_execution_run_id` set.
The result from the most recent completed run of this workflow. The SDK surfaces this to the new run via APIs such as `GetLastCompletionResult`.
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:
Serialized result of workflow failure (ex: An exception thrown, or error returned)
The `WORKFLOW_TASK_COMPLETED` event which this command was reported with
If another run is started by cron or retry, this contains the new run id.
Used in:
Versioning override upserted in this event. Ignored if nil or if unset_versioning_override is true.
Versioning override removed in this event.
Request ID attached to the running workflow execution so that subsequent requests with same request ID will be deduped.
Completion callbacks attached to the running workflow execution.
Optional. The identity of the client who initiated the request that created this event.
Priority override upserted in this event. Represents the full priority; not just partial fields. Ignored if nil.
TimeSkippingConfig override upserted in this event. Represents the full config.
Indicates the time skipping config was updated by the recent call to update workflow execution options.
Updates to workflow updates options.
Used in:
The ID of the workflow update this update options update corresponds to.
Request ID attached to the running workflow update so that subsequent requests with same request ID will be deduped
Completion callbacks attached to the running workflow update.
Attributes for an event marking that a workflow execution was paused.
Used in:
The identity of the client who paused the workflow execution.
The reason for pausing the workflow execution.
The request ID of the request that paused the workflow execution.
Used in:
The name/type of the signal to fire
Will be deserialized and provided as argument(s) to the signal handler
id of the worker/client who sent this signal
Headers that were passed by the sender of the signal and copied by temporal server into the workflow task.
Deprecated. This field is never respected and should always be set to false.
When signal origin is a workflow execution, this field is set.
The request ID of the Signal request, used by the server to attach this to the correct Event ID when generating link.
Always the first event in workflow history
Used in:
If this workflow is a child, the namespace our parent lives in. SDKs and UI tools should use `parent_workflow_namespace` field but server must use `parent_workflow_namespace_id` only.
Contains information about parent workflow execution that initiated the child workflow these attributes belong to. If the workflow these attributes belong to is not a child workflow of any other execution, this field will not be populated.
EventID of the child execution initiated event in parent workflow
SDK will deserialize this and provide it as arguments to the workflow function
Total workflow execution timeout including retries and continue as new.
Timeout of a single workflow run.
Timeout of a single workflow task.
Run id of the previous workflow which continued-as-new or retried or cron executed into this workflow.
This is the run id when the WorkflowExecutionStarted event was written. A workflow reset changes the execution run_id, but preserves this field.
Identity of the client who requested this execution
This is the very first runId along the chain of ContinueAsNew, Retry, Cron and Reset. Used to identify a chain.
Starting at 1, the number of times we have tried to execute this workflow
The absolute time at which the workflow will be timed out. This is passed without change to the next run/retry of a workflow.
If this workflow runs on a cron schedule, it will appear here
For a cron workflow, this contains the amount of time between when this iteration of the cron workflow was scheduled and when it should run next per its cron_schedule.
Version of the child execution initiated event in parent workflow It should be used together with parent_initiated_event_id to identify a child initiated event for global namespace
This field is new in 1.21.
If this workflow intends to use anything other than the current overall default version for the queue, then we include it here. Deprecated. [cleanup-experimental-wv]
Completion callbacks attached when this workflow was started.
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. When the workflow is its own root workflow, then root_workflow_execution is nil. 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. - W1 has root_workflow_execution set to nil. - W2 and W3 have root_workflow_execution set to W1. Scenario 2: Workflow W1 starts child workflow W2, and W2 continued as new W3. - The root workflow of all three workflows is W1. - W1 has root_workflow_execution set to nil. - W2 and W3 have root_workflow_execution set to W1. Scenario 3: Workflow W1 continued as new W2. - The root workflow of W1 is W1 and the root workflow of W2 is W2. - W1 and W2 have root_workflow_execution set to nil. Scenario 4: Workflow W1 starts child workflow W2, and W2 is reseted, creating W3 - The root workflow of all three workflows is W1. - W1 has root_workflow_execution set to nil. - W2 and W3 have root_workflow_execution set to W1. Scenario 5: Workflow W1 is reseted, creating W2. - The root workflow of W1 is W1 and the root workflow of W2 is W2. - W1 and W2 have root_workflow_execution set to nil.
When present, this execution is assigned to the build ID of its parent or previous execution. Deprecated. This field should be cleaned up when versioning-2 API is removed. [cleanup-experimental-wv]
Versioning override applied to this workflow when it was started. Children, crons, retries, and continue-as-new will inherit source run's override if pinned and if the new workflow's Task Queue belongs to the override version.
When present, it means this is a child workflow of a parent that is Pinned to this Worker Deployment Version. In this case, child workflow will start as Pinned to this Version instead of starting on the Current Version of its Task Queue. This is set only if the child workflow is starting on a Task Queue belonging to the same Worker Deployment Version. Deprecated. Use `parent_versioning_info`.
Priority metadata
If present, the new workflow should start on this version with pinned base behavior. Child of pinned parent will inherit the parent's version if the Child's Task Queue belongs to that version. A new run initiated by workflow ContinueAsNew of pinned run, will inherit the previous run's version if the new run's Task Queue belongs to that version. A new run initiated by workflow Cron will never inherit. A new run initiated by workflow Retry will only inherit if the retried run is effectively pinned at the time of retry, and the retried run inherited a pinned version when it started (ie. it is a child of a pinned parent, or a CaN of a pinned run, and is running on a Task Queue in the inherited version). Pinned override is inherited if Task Queue of new run is compatible with the override version. Override is inherited separately and takes precedence over inherited base version. Note: This field is mutually exclusive with inherited_auto_upgrade_info. Additionaly, versioning_override, if present, overrides this field during routing decisions.
If present, the new workflow begins with AutoUpgrade behavior. Before dispatching the first workflow task, this field is set to the deployment version on which the parent/ previous run was operating. This inheritance only happens when the task queues belong to the same deployment version. The first workflow task will then be dispatched to either this inherited deployment version, or the current deployment version of the task queue's Deployment. After the first workflow task, the effective behavior depends on worker-sent values in subsequent workflow tasks. Inheritance rules: - ContinueAsNew and child workflows: inherit AutoUpgrade behavior and deployment version - Cron: never inherits - Retry: inherits only if the retried run is effectively AutoUpgrade at the time of retry, and inherited AutoUpgrade behavior when it started (i.e. it is a child of an AutoUpgrade parent or ContinueAsNew of an AutoUpgrade run, running on the same deployment as the parent/previous run) Additional notes: - This field is mutually exclusive with `inherited_pinned_version`. - `versioning_override`, if present, overrides this field during routing decisions. - SDK implementations do not interact with this field and is only used internally by the server to ensure task routing correctness.
A boolean indicating whether the SDK has asked to eagerly execute the first workflow task for this workflow and eager execution was accepted by the server. Only populated by server with version >= 1.29.0.
During a previous run of this workflow, the server may have notified the SDK that the Target Worker Deployment Version changed, but the SDK declined to upgrade (e.g., by continuing-as-new with PINNED behavior). This field records the target version that was declined. This is a wrapper message to distinguish "never declined" (nil wrapper) from "declined an unversioned target" (non-nil wrapper with nil deployment_version). Used internally by the server during continue-as-new and retry. Should not be read or interpreted by SDKs.
Initial time-skipping configuration for this workflow execution, recorded at start time. This may have been set explicitly via the start workflow request, or propagated from a parent/previous execution. The configuration may be updated after start via UpdateWorkflowExecutionOptions, which will be reflected in the WorkflowExecutionOptionsUpdatedEvent.
The time-skipping state propagated from a previous run of this workflow. This can be nil if no time skipping has occurred or there is no previous run.
Used in:
User/client provided reason for termination
id of the client who requested termination
Attributes for an event indicating that time skipping state changed for a workflow execution, either time was advanced or time skipping was disabled automatically due to the fast_forward completing. The worker_may_ignore field in HistoryEvent should always be set true for this event.
Used in:
The virtual time point that time skipping advanced to.
When true, time skipping has been disabled automatically due to a call to fast_forward completing. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "after" is used to indicate temporal ordering. --)
The wall-clock time when the time-skipping state changed event was generated.
Used in:
If another run is started by cron or retry, this contains the new run id.
Attributes for an event marking that a workflow execution was unpaused.
Used in:
The identity of the client who unpaused the workflow execution.
The reason for unpausing the workflow execution.
The request ID of the request that unpaused the workflow execution.
Used in:
The instance ID of the update protocol that generated this event.
The message ID of the original request message that initiated this update. Needed so that the worker can recreate and deliver that same message as part of replay.
The event ID used to sequence the original request message.
The message payload of the original request message that initiated this update.
Used in:
The update request associated with this event.
An explanation of why this event was written to history.
Used in:
The metadata about this update.
The event ID indicating the acceptance of this update.
The outcome of executing the workflow update function.
Used in:
The instance ID of the update protocol that generated this event.
The message ID of the original request message that initiated this update. Needed so that the worker can recreate and deliver that same message as part of replay.
The event ID used to sequence the original request message.
The message payload of the original request message that initiated this update.
The cause of rejection.
Used in:
The `WORKFLOW_TASK_COMPLETED` event which this command was reported with
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.
Not used anywhere. Use case is replaced by WorkflowExecutionOptionsUpdatedEventAttributes
Used in:
Not used.
Not used.
Not used.
Not used.
Not used.
Used in:
The id of the `WORKFLOW_TASK_SCHEDULED` event this task corresponds to
The id of the `WORKFLOW_TASK_STARTED` event this task corresponds to
Identity of the worker who completed this task
Binary ID of the worker who completed this task Deprecated. Replaced with `deployment_version`.
Version info of the worker who processed this workflow task. If present, the `build_id` field within is also used as `binary_checksum`, which may be omitted in that case (it may also be populated to preserve compatibility). Deprecated. Use `deployment_version` and `versioning_behavior` instead.
Data the SDK wishes to record for itself, but server need not interpret, and does not directly impact workflow state.
Local usage data sent during workflow task completion and recorded here for posterity
The deployment that completed this task. May or may not be set for unversioned workers, depending on whether a value is sent by the SDK. This value updates workflow execution's `versioning_info.deployment`. Deprecated. Replaced with `deployment_version`.
Versioning behavior sent by the worker that completed this task for this particular workflow execution. UNSPECIFIED means the task was completed by an unversioned worker. This value updates workflow execution's `versioning_info.behavior`.
The Worker Deployment Version that completed this task. Must be set if `versioning_behavior` is set. This value updates workflow execution's `versioning_info.version`. Deprecated. Replaced with `deployment_version`.
The name of Worker Deployment that completed this task. Must be set if `versioning_behavior` is set. This value updates workflow execution's `worker_deployment_name`.
The Worker Deployment Version that completed this task. Must be set if `versioning_behavior` is set. This value updates workflow execution's `versioning_info.deployment_version`.
Used in:
The id of the `WORKFLOW_TASK_SCHEDULED` event this task corresponds to
The id of the `WORKFLOW_TASK_STARTED` event this task corresponds to
The failure details
If a worker explicitly failed this task, this field contains the worker's identity. When the server generates the failure internally this field is set as 'history-service'.
The original run id of the workflow. For reset workflow.
If the workflow is being reset, the new run id.
Version of the event where the history branch was forked. Used by multi-cluster replication during resets to identify the correct history branch.
Deprecated. This field should be cleaned up when versioning-2 API is removed. [cleanup-experimental-wv] If a worker explicitly failed this task, its binary id
Version info of the worker who processed this workflow task. If present, the `build_id` field within is also used as `binary_checksum`, which may be omitted in that case (it may also be populated to preserve compatibility). Deprecated. This field should be cleaned up when versioning-2 API is removed. [cleanup-experimental-wv]
Used in:
The task queue this workflow task was enqueued in, which could be a normal or sticky queue
How long the worker has to process this task once receiving it before it times out (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)
Starting at 1, how many attempts there have been to complete this task
Used in:
The id of the `WORKFLOW_TASK_SCHEDULED` event this task corresponds to
Identity of the worker who picked up this task
This field is populated from the RecordWorkflowTaskStartedRequest. Matching service would set the request_id on the RecordWorkflowTaskStartedRequest to a new UUID. This is useful in case a RecordWorkflowTaskStarted call succeed but matching doesn't get that response, so matching could retry and history service would return success if the request_id matches. In that case, matching will continue to deliver the task to worker. Without this field, history service would return AlreadyStarted error, and matching would drop the task.
True if this workflow should continue-as-new soon. See `suggest_continue_as_new_reasons` for why.
The reason(s) that suggest_continue_as_new is true, if it is. Unset if suggest_continue_as_new is false.
True if Workflow's Target Worker Deployment Version is different from its Pinned Version and the workflow is Pinned. Experimental.
Total history size in bytes, which the workflow might use to decide when to continue-as-new regardless of the suggestion. Note that history event count is just the event id of this event, so we don't include it explicitly here.
Version info of the worker to whom this task was dispatched. Deprecated. This field should be cleaned up when versioning-2 API is removed. [cleanup-experimental-wv]
Used by server internally to properly reapply build ID redirects to an execution when rebuilding it from events. Deprecated. This field should be cleaned up when versioning-2 API is removed. [cleanup-experimental-wv]
Used in:
The id of the `WORKFLOW_TASK_SCHEDULED` event this task corresponds to
The id of the `WORKFLOW_TASK_STARTED` event this task corresponds to