Get desktop application:
View/edit binary Protocol Buffers messages
WorkflowService API defines how Temporal SDKs and other clients interact with the Temporal server to create and interact with workflows and activities. Users are expected to call `StartWorkflowExecution` to create a new workflow execution. To drive workflows, a worker using a Temporal SDK must exist which regularly polls for workflow and activity tasks from the service. For each workflow task, the sdk must process the (incremental or complete) event history and respond back with any newly generated commands. For each activity task, the worker is expected to execute the user's code which implements that activity, responding with completion or failure.
CountActivityExecutions is a visibility API to count activity executions in a specific namespace.
Visibility query, see https://docs.temporal.io/list-filter for the syntax.
If `query` is not grouping by any field, the count is an approximate number of activities that match the query. If `query` is grouping by a field, the count is simply the sum of the counts of the groups returned in the response. This number can be smaller than the total number of activities matching the query.
Contains the groups if the request is grouping by a field. The list might not be complete, and the counts of each group is approximate.
CountNexusOperationExecutions is a visibility API to count Nexus operations in a specific namespace.
Visibility query, see https://docs.temporal.io/list-filter for the syntax. See also ListNexusOperationExecutionsRequest for search attributes available for Nexus operations.
If `query` is not grouping by any field, the count is an approximate number of operations that match the query. If `query` is grouping by a field, the count is simply the sum of the counts of the groups returned in the response. This number can be smaller than the total number of operations matching the query.
Contains the groups if the request is grouping by a field. The list might not be complete, and the counts of each group is approximate.
CountSchedules is a visibility API to count schedules in a specific namespace.
Visibility query, see https://docs.temporal.io/list-filter for the syntax.
If `query` is not grouping by any field, the count is an approximate number of schedules that match the query. If `query` is grouping by a field, the count is simply the sum of the counts of the groups returned in the response. This number can be smaller than the total number of schedules matching the query.
Contains the groups if the request is grouping by a field. The list might not be complete, and the counts of each group is approximate.
CountWorkers counts the number of workers in a specific namespace.
Query to filter workers before counting. Supported filter fields are the same as in ListWorkersRequest.
When true, the count will include system workers that are created implicitly by the server and not by the user. By default, system workers are excluded.
Number of workers matching the query.
CountWorkflowExecutions is a visibility API to count of workflow executions in a specific namespace.
If `query` is not grouping by any field, the count is an approximate number of workflows that matches the query. If `query` is grouping by a field, the count is simply the sum of the counts of the groups returned in the response. This number can be smaller than the total number of workflows matching the query.
`groups` contains the groups if the request is grouping by a field. The list might not be complete, and the counts of each group is approximate.
Creates a new schedule.
(-- api-linter: core::0203::optional=disabled aip.dev/not-precedent: field_behavior annotation not available in our gogo fork --)
The namespace the schedule should be created in.
The id of the new schedule.
The schedule spec, policies, action, and initial state.
Optional initial patch (e.g. to run the action once immediately).
The identity of the client who initiated this request.
A unique identifier for this create request for idempotence. Typically UUIDv4.
Memo and search attributes to attach to the schedule itself.
Creates a new Worker Deployment. Experimental. This API might significantly change or be removed in a future release.
Creates a new WorkerDeployment.
The name of the Worker Deployment to create. If a Worker Deployment with this name already exists, an error will be returned.
Optional. The identity of the client who initiated this request.
A unique identifier for this create request for idempotence. Typically UUIDv4.
This value is returned so that it can be optionally passed to APIs that write to the WorkerDeployment state to ensure that the state did not change between this API call and a future write.
Creates a new Worker Deployment Version. Experimental. This API might significantly change or be removed in a future release.
Creates a new WorkerDeploymentVersion.
Required.
Optional. Contains the new worker compute configuration for the Worker Deployment. Used for worker scale management.
Optional. The identity of the client who initiated this request.
A unique identifier for this create request for idempotence. Typically UUIDv4. If a second request with the same ID is recieved, it is considered a successful no-op. Retrying with a different request ID for the same deployment name + build ID is an error.
(message has no fields)
Create a new workflow rule. The rules are used to control the workflow execution. The rule will be applied to all running and new workflows in the namespace. If the rule with such ID already exist this call will fail Note: the rules are part of namespace configuration and will be stored in the namespace config. Namespace config is eventually consistent.
The rule specification .
If true, the rule will be applied to the currently running workflows via batch job. If not set , the rule will only be applied when triggering condition is satisfied. visibility_query in the rule will be used to select the workflows to apply the rule to.
Used to de-dupe requests. Typically should be UUID.
Identity of the actor who created the rule. Will be stored with the rule.
Rule description.Will be stored with the rule.
Created rule.
Batch Job ID if force-scan flag was provided. Otherwise empty.
DeleteActivityExecution asynchronously deletes a specific activity execution (when ActivityExecution.run_id is provided) or the latest activity execution (when ActivityExecution.run_id is not provided). If the activity Execution is running, it will be terminated before deletion. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: Activity deletion not exposed to HTTP, users should use cancel or terminate. --)
Activity run ID, targets the latest run if run_id is empty.
(message has no fields)
DeleteNexusOperationExecution asynchronously deletes a specific Nexus operation run (when run_id is provided) or the latest run (when run_id is not provided). If the operation is running, it will be terminated before deletion. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: Nexus operation deletion not exposed to HTTP, users should use cancel or terminate. --)
Operation run ID, targets the latest run if empty.
(message has no fields)
Deletes a schedule, removing it from the system.
The namespace of the schedule to delete.
The id of the schedule to delete.
The identity of the client who initiated this request.
(message has no fields)
Deletes records of (an old) Deployment. A deployment can only be deleted if it has no Version in it. Experimental. This API might significantly change or be removed in a future release.
Deletes records of (an old) Deployment. A deployment can only be deleted if it has no Version in it.
Optional. The identity of the client who initiated this request.
(message has no fields)
Used for manual deletion of Versions. User can delete a Version only when all the following conditions are met: - It is not the Current or Ramping Version of its Deployment. - It has no active pollers (none of the task queues in the Version have pollers) - It is not draining (see WorkerDeploymentVersionInfo.drainage_info). This condition can be skipped by passing `skip-drainage=true`. Experimental. This API might significantly change or be removed in a future release.
Used for manual deletion of Versions. User can delete a Version only when all the following conditions are met: - It is not the Current or Ramping Version of its Deployment. - It has no active pollers (none of the task queues in the Version have pollers) - It is not draining (see WorkerDeploymentVersionInfo.drainage_info). This condition can be skipped by passing `skip-drainage=true`.
Deprecated. Use `deployment_version`.
Required.
Pass to force deletion even if the Version is draining. In this case the open pinned workflows will be stuck until manually moved to another version by UpdateWorkflowExecutionOptions.
Optional. The identity of the client who initiated this request.
(message has no fields)
DeleteWorkflowExecution asynchronously deletes a specific Workflow Execution (when WorkflowExecution.run_id is provided) or the latest Workflow Execution (when WorkflowExecution.run_id is not provided). If the Workflow Execution is Running, it will be terminated before deletion. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: Workflow deletion not exposed to HTTP, users should use cancel or terminate. --)
Workflow Execution to delete. If run_id is not specified, the latest one is used.
(message has no fields)
Delete rule by rule id
ID of the rule to delete. Unique within the namespace.
(message has no fields)
DeprecateNamespace is used to update the state of a registered namespace to DEPRECATED. Once the namespace is deprecated it cannot be used to start new workflow executions. Existing workflow executions will continue to run on deprecated namespaces. Deprecated. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: Deprecated --)
Deprecated.
Deprecated.
(message has no fields)
DescribeActivityExecution returns information about an activity execution. It can be used to: - Get current activity info without waiting - Long-poll for next state change and return new activity info Response can optionally include activity input or outcome (if the activity has completed).
Activity run ID. If empty the request targets the latest run.
Include the input field in the response.
Include the outcome (result/failure) in the response if the activity has completed.
Token from a previous DescribeActivityExecutionResponse. If present, long-poll until activity state changes from the state encoded in this token. If absent, return current state immediately. If present, run_id must also be present. Note that activity state may change multiple times between requests, therefore it is not guaranteed that a client making a sequence of long-poll requests will see a complete sequence of state changes.
Include the heartbeat_details field inside info in the response if available.
Include the last_failure field inside info in the response if available.
The run ID of the activity, useful when run_id was not specified in the request.
Information about the activity execution. Fields heartbeat_details and last_failure are omitted unless the request has include_heartbeat_details or include_last_failure set to true, respectively.
Serialized activity input, passed as arguments to the activity function. Only set if include_input was true in the request.
Only set if the activity is completed and include_outcome was true in the request.
Token for follow-on long-poll requests. Absent only if the activity is complete.
Callbacks attached to this activity execution and their current state.
DescribeBatchOperation returns the information about a batch operation
Namespace that contains the batch operation
Batch job id
Batch operation type
Batch job ID
Batch operation state
Batch operation start time
Batch operation close time
Total operation count
Complete operation count
Failure operation count
Identity indicates the operator identity
Reason indicates the reason to stop a operation
Describes a worker deployment. Experimental. This API might significantly change or be removed in a future release. Deprecated. Replaced with `DescribeWorkerDeploymentVersion`.
[cleanup-wv-pre-release] Pre-release deployment APIs, clean up later
[cleanup-wv-pre-release] Pre-release deployment APIs, clean up later
DescribeNamespace returns the information and configuration for a registered namespace.
If true, the server may serve the response from an eventually-consistent source instead of reading through to persistence. Defaults to false, which preserves read-after-write consistency. SDKs should set this when fetching namespace capabilities on worker/client startup.
DescribeNexusOperationExecution returns information about a Nexus operation. Supported use cases include: - Get current operation info without waiting - Long-poll for next state change and return new operation info Response can optionally include operation input or outcome (if the operation has completed).
Operation run ID. If empty the request targets the latest run.
Include the input field in the response.
Include the outcome (result/failure) in the response if the operation has completed.
Token from a previous DescribeNexusOperationExecutionResponse. If present, this RPC will long-poll until operation state changes from the state encoded in this token. If absent, return current state immediately. If present, run_id must also be present. Note that operation state may change multiple times between requests, therefore it is not guaranteed that a client making a sequence of long-poll requests will see a complete sequence of state changes.
The run ID of the operation, useful when run_id was not specified in the request.
Information about the operation.
Serialized operation input, passed as the request payload. Only set if include_input was true in the request.
Only set if the operation is completed and include_outcome was true in the request.
The result if the operation completed successfully.
The failure if the operation completed unsuccessfully.
Token for follow-on long-poll requests. Absent only if the operation is complete.
Returns the schedule description and current state of an existing schedule.
The namespace of the schedule to describe.
The id of the schedule to describe.
The complete current schedule details. This may not match the schedule as created because: - some types of schedule specs may get compiled into others (e.g. CronString into StructuredCalendarSpec) - some unspecified fields may be replaced by defaults - some fields in the state are modified automatically - the schedule may have been modified by UpdateSchedule or PatchSchedule
Extra schedule state info.
The memo and search attributes that the schedule was created with.
This value can be passed back to UpdateSchedule to ensure that the schedule was not modified between a Describe and an Update, which could lead to lost updates and other confusion.
DescribeTaskQueue returns the following information about the target task queue, broken down by Build ID: - List of pollers - Workflow Reachability status - Backlog info for Workflow and/or Activity tasks
(-- api-linter: core::0203::optional=disabled aip.dev/not-precedent: field_behavior annotation not available in our gogo fork --)
Sticky queues are not supported in deprecated ENHANCED mode.
If unspecified (TASK_QUEUE_TYPE_UNSPECIFIED), then default value (TASK_QUEUE_TYPE_WORKFLOW) will be used. Only supported in default mode (use `task_queue_types` in ENHANCED mode instead).
Report stats for the requested task queue type(s).
Report Task Queue Config
Deprecated, use `report_stats` instead. If true, the task queue status will be included in the response.
Deprecated. ENHANCED mode is also being deprecated. Select the API mode to use for this request: DEFAULT mode (if unset) or ENHANCED mode. Consult the documentation for each field to understand which mode it is supported in.
Deprecated (as part of the ENHANCED mode deprecation). Optional. If not provided, the result for the default Build ID will be returned. The default Build ID is the one mentioned in the first unconditional Assignment Rule. If there is no default Build ID, the result for the unversioned queue will be returned. (-- api-linter: core::0140::prepositions --)
Deprecated (as part of the ENHANCED mode deprecation). Task queue types to report info about. If not specified, all types are considered.
Deprecated (as part of the ENHANCED mode deprecation). Report list of pollers for requested task queue types and versions.
Deprecated (as part of the ENHANCED mode deprecation). Report task reachability for the requested versions and all task types (task reachability is not reported per task type).
Statistics for the task queue. Only set if `report_stats` is set on the request.
Task queue stats breakdown by priority key. Only contains actively used priority keys. Only set if `report_stats` is set on the request. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "by" is used to clarify the keys and values. --)
Specifies which Worker Deployment Version(s) Server routes this Task Queue's tasks to. When not present, it means the tasks are routed to Unversioned workers (workers with UNVERSIONED or unspecified WorkerVersioningMode.) Task Queue Versioning info is updated indirectly by calling SetWorkerDeploymentCurrentVersion and SetWorkerDeploymentRampingVersion on Worker Deployments. Note: This information is not relevant to Pinned workflow executions and their activities as they are always routed to their Pinned Deployment Version. However, new workflow executions are typically not Pinned until they complete their first task (unless they are started with a Pinned VersioningOverride or are Child Workflows of a Pinned parent).
Only populated if report_task_queue_config is set to true.
Deprecated. Status of the task queue. Only populated when `include_task_queue_status` is set to true in the request.
Deprecated. Only returned in ENHANCED mode. This map contains Task Queue information for each Build ID. Empty string as key value means unversioned.
DescribeWorker returns information about the specified worker.
Namespace this worker belongs to.
Worker instance key to describe.
Describes a Worker Deployment. Experimental. This API might significantly change or be removed in a future release.
This value is returned so that it can be optionally passed to APIs that write to the Worker Deployment state to ensure that the state did not change between this read and a future write.
Describes a worker deployment version. Experimental. This API might significantly change or be removed in a future release.
Deprecated. Use `deployment_version`.
Required.
Report stats for task queues which have been polled by this version.
All the Task Queues that have ever polled from this Deployment version.
DescribeWorkflowExecution returns information about the specified workflow execution.
DescribeWorkflowRule return the rule specification for existing rule id. If there is no rule with such id - NOT FOUND error will be returned.
User-specified ID of the rule to read. Unique within the namespace.
The rule that was read.
ExecuteMultiOperation executes multiple operations within a single workflow. Operations are started atomically, meaning if *any* operation fails to be started, none are, and the request fails. Upon start, the API returns only when *all* operations have a response. Upon failure, it returns `MultiOperationExecutionFailure` where the status code equals the status code of the *first* operation that failed to be started. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: To be exposed over HTTP in the future. --)
List of operations to execute within a single workflow. Preconditions: - The list of operations must not be empty. - The workflow ids must match across operations. - The only valid list of operations at this time is [StartWorkflow, UpdateWorkflow], in this order. Note that additional operation-specific restrictions have to be considered.
Resource ID for routing. Should match operations[0].start_workflow.workflow_id
IMPORTANT: For [StartWorkflow, UpdateWorkflow] combination ("Update-with-Start") when both 1. the workflow update for the requested update ID has already completed, and 2. the workflow for the requested workflow ID has already been closed, then you'll receive - an update response containing the update's outcome, and - a start response with a `status` field that reflects the workflow's current state.
FetchWorkerConfig returns the worker configuration for a specific worker.
Namespace this worker belongs to.
The identity of the client who initiated this request.
Reason for sending worker command, can be used for audit purpose.
Defines which workers should receive this command. only single worker is supported at this time.
Resource ID for routing. Contains the worker grouping key.
The worker configuration.
GetClusterInfo returns information about temporal cluster
(message has no fields)
GetClusterInfoResponse contains information about Temporal cluster.
Key is client name i.e "temporal-go", "temporal-java", or "temporal-cli". Value is ranges of supported versions of this client i.e ">1.1.1 <=1.4.0 || ^5.0.0".
Returns the current deployment (and its info) for a given deployment series. Experimental. This API might significantly change or be removed in a future release. Deprecated. Replaced by `current_version` returned by `DescribeWorkerDeployment`.
Returns the Current Deployment of a deployment series. [cleanup-wv-pre-release] Pre-release deployment APIs, clean up later
[cleanup-wv-pre-release] Pre-release deployment APIs, clean up later
Returns the reachability level of a worker deployment to help users decide when it is time to decommission a deployment. Reachability level is calculated based on the deployment's `status` and existing workflows that depend on the given deployment for their execution. Calculating reachability is relatively expensive. Therefore, server might return a recently cached value. In such a case, the `last_update_time` will inform you about the actual reachability calculation time. Experimental. This API might significantly change or be removed in a future release. Deprecated. Replaced with `DrainageInfo` returned by `DescribeWorkerDeploymentVersion`.
[cleanup-wv-pre-release] Pre-release deployment APIs, clean up later
[cleanup-wv-pre-release] Pre-release deployment APIs, clean up later
Reachability level might come from server cache. This timestamp specifies when the value was actually calculated.
GetSearchAttributes is a visibility API to get all legal keys that could be used in list APIs (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: We do not expose this search attribute API to HTTP (but may expose on OperatorService). --)
(message has no fields)
GetSystemInfo returns information about the system.
(message has no fields)
Version of the server.
All capabilities the system supports.
Deprecated. Use `GetWorkerVersioningRules`. Will be removed in server version v1.32.0. Fetches the worker build id versioning sets for a task queue.
[cleanup-wv-pre-release]
Must be set, the task queue to interrogate about worker id compatibility.
Limits how many compatible sets will be returned. Specify 1 to only return the current default major version set. 0 returns all sets.
[cleanup-wv-pre-release]
Major version sets, in order from oldest to newest. The last element of the list will always be the current default major version. IE: New workflows will target the most recent version in that version set. There may be fewer sets returned than exist, if the request chose to limit this response.
Deprecated. Use `DescribeTaskQueue`. Will be removed in server version v1.32.0. Fetches task reachability to determine whether a worker may be retired. The request may specify task queues to query for or let the server fetch all task queues mapped to the given build IDs. When requesting a large number of task queues or all task queues associated with the given build ids in a namespace, all task queues will be listed in the response but some of them may not contain reachability information due to a server enforced limit. When reaching the limit, task queues that reachability information could not be retrieved for will be marked with a single TASK_REACHABILITY_UNSPECIFIED entry. The caller may issue another call to get the reachability for those task queues. Open source users can adjust this limit by setting the server's dynamic config value for `limit.reachabilityTaskQueueScan` with the caveat that this call can strain the visibility store.
[cleanup-wv-pre-release] Deprecated. Use `DescribeTaskQueue`.
Build ids to retrieve reachability for. An empty string will be interpreted as an unversioned worker. The number of build ids that can be queried in a single API call is limited. Open source users can adjust this limit by setting the server's dynamic config value for `limit.reachabilityQueryBuildIds` with the caveat that this call can strain the visibility store.
Task queues to retrieve reachability for. Leave this empty to query for all task queues associated with given build ids in the namespace. Must specify at least one task queue if querying for an unversioned worker. The number of task queues that the server will fetch reachability information for is limited. See the `GetWorkerTaskReachabilityResponse` documentation for more information.
Type of reachability to query for. `TASK_REACHABILITY_NEW_WORKFLOWS` is always returned in the response. Use `TASK_REACHABILITY_EXISTING_WORKFLOWS` if your application needs to respond to queries on closed workflows. Otherwise, use `TASK_REACHABILITY_OPEN_WORKFLOWS`. Default is `TASK_REACHABILITY_EXISTING_WORKFLOWS` if left unspecified. See the TaskReachability docstring for information about each enum variant.
[cleanup-wv-pre-release] Deprecated. Use `DescribeTaskQueue`.
Task reachability, broken down by build id and then task queue. When requesting a large number of task queues or all task queues associated with the given build ids in a namespace, all task queues will be listed in the response but some of them may not contain reachability information due to a server enforced limit. When reaching the limit, task queues that reachability information could not be retrieved for will be marked with a single TASK_REACHABILITY_UNSPECIFIED entry. The caller may issue another call to get the reachability for those task queues. Open source users can adjust this limit by setting the server's dynamic config value for `limit.reachabilityTaskQueueScan` with the caveat that this call can strain the visibility store.
Fetches the Build ID assignment and redirect rules for a Task Queue. Will be removed in server version v1.32.0.
[cleanup-wv-pre-release]
[cleanup-wv-pre-release]
This value can be passed back to UpdateWorkerVersioningRulesRequest to ensure that the rules were not modified between this List and the Update, which could lead to lost updates and other confusion.
GetWorkflowExecutionHistory returns the history of specified workflow execution. Fails with `NotFound` if the specified workflow execution is unknown to the service.
If a `GetWorkflowExecutionHistoryResponse` or a `PollWorkflowTaskQueueResponse` had one of these, it should be passed here to fetch the next page.
If set to true, the RPC call will not resolve until there is a new event which matches the `history_event_filter_type`, or a timeout is hit.
Filter returned events such that they match the specified filter type. Default: HISTORY_EVENT_FILTER_TYPE_ALL_EVENT.
Raw history is an alternate representation of history that may be returned if configured on the frontend. This is not supported by all SDKs. Either this or `history` will be set.
Will be set if there are more history events than were included in this response
GetWorkflowExecutionHistoryReverse returns the history of specified workflow execution in reverse order (starting from last event). Fails with`NotFound` if the specified workflow execution is unknown to the service.
Will be set if there are more history events than were included in this response
ListActivityExecutions is a visibility API to list activity executions in a specific namespace.
Max number of executions to return per page.
Token returned in ListActivityExecutionsResponse.
Visibility query, see https://docs.temporal.io/list-filter for the syntax.
Token to use to fetch the next page. If empty, there is no next page.
ListArchivedWorkflowExecutions is a visibility API to list archived workflow executions in a specific namespace.
ListBatchOperations returns a list of batch operations
Namespace that contains the batch operation
List page size
Next page token
BatchOperationInfo contains the basic info about batch operation
ListClosedWorkflowExecutions is a visibility API to list the closed executions in a specific namespace. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: HTTP users should use ListWorkflowExecutions instead. --)
Lists worker deployments in the namespace. Optionally can filter based on deployment series name. Experimental. This API might significantly change or be removed in a future release. Deprecated. Replaced with `ListWorkerDeployments`.
[cleanup-wv-pre-release] Pre-release deployment APIs, clean up later
Optional. Use to filter based on exact series name match.
[cleanup-wv-pre-release] Pre-release deployment APIs, clean up later
ListNamespaces returns the information and configuration for all namespaces.
ListNexusOperationExecutions is a visibility API to list Nexus operations in a specific namespace.
Max number of operations to return per page.
Token returned in ListNexusOperationExecutionsResponse.
Visibility query, see https://docs.temporal.io/list-filter for the syntax. Search attributes that are avaialble for Nexus operations include: - OperationId - RunId - Endpoint - Service - Operation - RequestId - StartTime - ExecutionTime - CloseTime - ExecutionStatus - ExecutionDuration - StateTransitionCount
Token to use to fetch the next page. If empty, there is no next page.
ListOpenWorkflowExecutions is a visibility API to list the open executions in a specific namespace. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: HTTP users should use ListWorkflowExecutions instead. --)
Lists matching times within a range.
The namespace of the schedule to query.
The id of the schedule to query.
Time range to query.
List all schedules in a namespace.
The namespace to list schedules in.
How many to return at once.
Token to get the next page of results.
Query to filter schedules.
(-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: We do not expose this low-level API to HTTP. --)
Lists all Worker Deployments that are tracked in the Namespace. Experimental. This API might significantly change or be removed in a future release.
The list of worker deployments.
ListWorkers is a visibility API to list worker status information in a specific namespace.
`query` in ListWorkers is used to filter workers based on worker attributes. Supported attributes: * WorkerInstanceKey * WorkerIdentity * HostName * TaskQueue * DeploymentName * BuildId * SdkName * SdkVersion * StartTime * Status
When true, the response will include system workers that are created implicitly by the server and not by the user. By default, system workers are excluded.
Deprecated: Use workers instead. This field returns full WorkerInfo which includes expensive runtime metrics. We will stop populating this field in the future.
Limited worker information.
Next page token
ListWorkflowExecutions is a visibility API to list workflow executions in a specific namespace.
Return all namespace workflow rules
Makes a specific change to a schedule or triggers an immediate action.
The namespace of the schedule to patch.
The id of the schedule to patch.
The identity of the client who initiated this request.
A unique identifier for this update request for idempotence. Typically UUIDv4.
(message has no fields)
PauseActivity pauses the execution of an activity specified by its ID or type. If there are multiple pending activities of the provided type - all of them will be paused Pausing an activity means: - If the activity is currently waiting for a retry or is running and subsequently fails, it will not be rescheduled until it is unpaused. - If the activity is already paused, calling this method will have no effect. - If the activity is running and finishes successfully, the activity will be completed. - If the activity is running and finishes with failure: * if there is no retry left - the activity will be completed. * if there are more retries left - the activity will be paused. For long-running activities: - activities in paused state will send a cancellation with "activity_paused" set to 'true' in response to 'RecordActivityTaskHeartbeat'. - The activity should respond to the cancellation accordingly. Returns a `NotFound` error if there is no pending activity with the provided ID or type This API will be deprecated soon and replaced with a newer PauseActivityExecution that is better named and structured to work well for standalone activities.
Deprecated. Use `PauseActivityExecutionRequest`.
Namespace of the workflow which scheduled this activity.
Execution info of the workflow which scheduled this activity
The identity of the client who initiated this request.
either activity id or activity type must be provided
Only the activity with this ID will be paused.
Pause all running activities of this type. Note: Experimental - the behavior of pause by activity type might change in a future release.
Reason to pause the activity.
Used to de-dupe pause requests.
Deprecated. Use `PauseActivityExecutionResponse`.
(message has no fields)
PauseActivityExecution pauses the execution of an activity specified by its ID. This API can be used to target a workflow activity or a standalone activity Pausing an activity means: - If the activity is currently waiting for a retry or is running and subsequently fails, it will not be rescheduled until it is unpaused. - If the activity is already paused, calling this method will have no effect. - If the activity is running and finishes successfully, the activity will be completed. - If the activity is running and finishes with failure: * if there is no retry left - the activity will be completed. * if there are more retries left - the activity will be paused. For long-running activities: - activities in paused state will send a cancellation with "activity_paused" set to 'true' in response to 'RecordActivityTaskHeartbeat'. Returns a `NotFound` error if there is no pending activity with the provided ID
Namespace of the workflow which scheduled this activity.
If provided, pause a workflow activity (or activities) for the given workflow ID. If empty, targets a standalone activity.
The ID of the activity to target.
Run ID of the workflow or standalone activity.
The identity of the client who initiated this request.
Reason to pause the activity.
Resource ID for routing. Contains "workflow:{workflow_id}" for workflow activities or "activity:{activity_id}" for standalone activities.
Used to de-dupe pause requests.
(message has no fields)
Note: This is an experimental API and the behavior may change in a future release. PauseWorkflowExecution pauses the workflow execution specified in the request. Pausing a workflow execution results in - The workflow execution status changes to `PAUSED` and a new WORKFLOW_EXECUTION_PAUSED event is added to the history - No new workflow tasks or activity tasks are dispatched. - Any workflow task currently executing on the worker will be allowed to complete. - Any activity task currently executing will be paused. - All server-side events will continue to be processed by the server. - Queries & Updates on a paused workflow will be rejected.
Request to pause a workflow execution.
Namespace of the workflow to pause.
ID of the workflow execution to be paused. Required.
Run ID of the workflow execution to be paused. Optional. If not provided, the current run of the workflow will be paused.
The identity of the client who initiated this request.
Reason to pause the workflow execution.
A unique identifier for this pause request for idempotence. Typically UUIDv4.
Response to a successful PauseWorkflowExecution request.
(message has no fields)
PollActivityExecution long-polls for an activity execution to complete and returns the outcome (result or failure).
Activity run ID. If empty the request targets the latest run.
The run ID of the activity, useful when run_id was not specified in the request.
PollActivityTaskQueue is called by workers to process activity tasks from a specific task queue. The worker is expected to call one of the `RespondActivityTaskXXX` methods when it is done processing the task. An activity task is dispatched whenever a `SCHEDULE_ACTIVITY_TASK` command is produced during workflow execution. An in memory `ACTIVITY_TASK_STARTED` event is written to mutable state before the task is dispatched to the worker. The started event, and the final event (`ACTIVITY_TASK_COMPLETED` / `ACTIVITY_TASK_FAILED` / `ACTIVITY_TASK_TIMED_OUT`) will both be written permanently to Workflow execution history when Activity is finished. This is done to avoid writing many events in the case of a failure/retry loop. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: We do not expose worker API to HTTP. --)
Unless this is the first poll, the client must pass one of the poller group IDs received in `poller_group_infos` of the last the PollActivityTaskQueueResponse according to the instructions. If not set, the poll is routed randomly which can cause it to be blocked without receiving a task while the queue actually has tasks in another server location.
The identity of the worker/client
A unique key for this worker instance, used for tracking worker lifecycle. This is guaranteed to be unique, whereas identity is not guaranteed to be unique.
A dedicated per-worker Nexus task queue on which the server sends control tasks (e.g. activity cancellation) to this specific worker instance.
Information about this worker's build identifier and if it is choosing to use the versioning feature. See the `WorkerVersionCapabilities` docstring for more. Deprecated. Replaced by deployment_options.
Worker deployment options that user has set in the worker.
PollNexusOperationExecution long-polls for a Nexus operation for a given wait stage to complete and returns the outcome (result or failure).
Operation run ID. If empty the request targets the latest run.
Stage to wait for. The operation may be in a more advanced stage when the poll is unblocked.
The run ID of the operation, useful when run_id was not specified in the request.
The current stage of the operation. May be more advanced than the stage requested in the poll.
Operation token. Only populated for asynchronous operations after a successful StartOperation call.
The operation outcome, available if the operation is in a closed state.
The result if the operation completed successfully.
The failure if the operation completed unsuccessfully.
PollNexusTaskQueue is a long poll call used by workers to receive Nexus tasks. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: We do not expose worker API to HTTP. --)
Unless this is the first poll, the client must pass one of the poller group IDs received in `poller_group_infos` of the last the PollNexusTaskQueueResponse according to the instructions. If not set, the poll is routed randomly which can cause it to be blocked without receiving a task while the queue actually has tasks in another server location.
The identity of the client who initiated this request.
A unique key for this worker instance, used for tracking worker lifecycle. This is guaranteed to be unique, whereas identity is not guaranteed to be unique.
Information about this worker's build identifier and if it is choosing to use the versioning feature. See the `WorkerVersionCapabilities` docstring for more. Deprecated. Replaced by deployment_options.
Worker deployment options that user has set in the worker.
Worker info to be sent to the server.
An opaque unique identifier for this task for correlating a completion request the embedded request.
Embedded request as translated from the incoming frontend request.
Server-advised information the SDK may use to adjust its poller count.
This poller group ID identifies the owner of the nexus task awaiting for synchronous response. Corresponding `RespondNexusTaskCompleted` and `RespondNexusTaskFailed` calls should pass this value for proper response routing.
The weighted list of poller groups IDs that client should use for future polls to this task queue. Client is expected to: 1. Maintain minimum number of pollers no less than the number of groups. 2. Try to assign the next poll to a group without any pending polls, 3. If every group has some pending polls, assign the next poll to a group randomly according to the weights.
Polls a Workflow Execution for the outcome of a Workflow Update previously issued through the UpdateWorkflowExecution RPC. The effective timeout on this call will be shorter of the the caller-supplied gRPC timeout and the server's configured long-poll timeout. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: We don't expose update polling API to HTTP in favor of a potential future non-blocking form. --)
The namespace of the Workflow Execution to which the Update was originally issued.
The Update reference returned in the initial UpdateWorkflowExecutionResponse.
The identity of the worker/client who is polling this Update outcome.
Specifies client's intent to wait for Update results. Omit to request a non-blocking poll.
The outcome of the update if and only if the update has completed. If this response is being returned before the update has completed (e.g. due to the specification of a wait policy that only waits on UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_ACCEPTED) then this field will not be set.
The most advanced lifecycle stage that the Update is known to have reached, where lifecycle stages are ordered UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_UNSPECIFIED < UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_ADMITTED < UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_ACCEPTED < UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_COMPLETED. UNSPECIFIED will be returned if and only if the server's maximum wait time was reached before the Update reached the stage specified in the request WaitPolicy, and before the context deadline expired; clients may may then retry the call as needed.
Sufficient information to address this Update.
PollWorkflowTaskQueue is called by workers to make progress on workflows. A WorkflowTask is dispatched to callers for active workflow executions with pending workflow tasks. The worker is expected to call `RespondWorkflowTaskCompleted` when it is done processing the task. The service will create a `WorkflowTaskStarted` event in the history for this task before handing it to the worker. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: We do not expose worker API to HTTP. --)
Unless this is the first poll, the client must pass one of the poller group IDs received in `poller_group_infos` of the last the PollWorkflowTaskQueueResponse according to the instructions. If not set, the poll is routed randomly which can cause it to be blocked without receiving a task while the queue actually has tasks in another server location.
The identity of the worker/client who is polling this task queue
A unique key for this worker instance, used for tracking worker lifecycle. This is guaranteed to be unique, whereas identity is not guaranteed to be unique.
A dedicated per-worker Nexus task queue on which the server sends control tasks (e.g. activity cancellation) to this specific worker instance.
Deprecated. Use deployment_options instead. Each worker process should provide an ID unique to the specific set of code it is running "checksum" in this field name isn't very accurate, it should be though of as an id.
Deprecated. Use deployment_options instead. Information about this worker's build identifier and if it is choosing to use the versioning feature. See the `WorkerVersionCapabilities` docstring for more.
Worker deployment options that user has set in the worker.
QueryWorkflow requests a query be executed for a specified workflow execution.
QueryRejectCondition can used to reject the query if workflow state does not satisfy condition. Default: QUERY_REJECT_CONDITION_NONE.
RecordActivityTaskHeartbeat is optionally called by workers while they execute activities. If a worker fails to heartbeat within the `heartbeat_timeout` interval for the activity task, then the current attempt times out. Depending on RetryPolicy, this may trigger a retry or time out the activity. For workflow activities, an `ACTIVITY_TASK_TIMED_OUT` event will be written to the workflow history. Calling `RecordActivityTaskHeartbeat` will fail with `NotFound` in such situations, in that event, the SDK should request cancellation of the activity. The request may contain response `details` which will be persisted by the server and may be used by the activity to checkpoint progress. The `cancel_requested` field in the response indicates whether cancellation has been requested for the activity.
The task token as received in `PollActivityTaskQueueResponse`
Arbitrary data, of which the most recent call is kept, to store for this activity
The identity of the worker/client
Resource ID for routing. Contains the workflow ID or activity ID for standalone activities.
Will be set to true if the activity has been asked to cancel itself. The SDK should then notify the activity of cancellation if it is still running.
Will be set to true if the activity is paused.
Will be set to true if the activity was reset. Applies only to the current run.
See `RecordActivityTaskHeartbeat`. This version allows clients to record heartbeats by namespace/workflow id/activity id instead of task token. (-- api-linter: core::0136::prepositions=disabled aip.dev/not-precedent: "By" is used to indicate request type. --)
Namespace of the workflow which scheduled this activity
Id of the workflow which scheduled this activity, leave empty to target a standalone activity
For a workflow activity - the run ID of the workflow which scheduled this activity. For a standalone activity - the run ID of the activity.
Id of the activity we're heartbeating
Arbitrary data, of which the most recent call is kept, to store for this activity
The identity of the worker/client
Resource ID for routing. Contains "workflow:workflow_id" or "activity:activity_id" for standalone activities.
Will be set to true if the activity has been asked to cancel itself. The SDK should then notify the activity of cancellation if it is still running.
Will be set to true if the activity is paused.
Will be set to true if the activity was reset. Applies only to the current run.
WorkerHeartbeat receive heartbeat request from the worker.
Namespace this worker belongs to.
The identity of the client who initiated this request.
Resource ID for routing. Contains the worker grouping key.
(message has no fields)
RegisterNamespace creates a new namespace which can be used as a container for all resources. A Namespace is a top level entity within Temporal, and is used as a container for resources like workflow executions, task queues, etc. A Namespace acts as a sandbox and provides isolation for all resources within the namespace. All resources belongs to exactly one namespace.
A key-value map for any customized purpose.
If unspecified (ARCHIVAL_STATE_UNSPECIFIED) then default server configuration is used.
If unspecified (ARCHIVAL_STATE_UNSPECIFIED) then default server configuration is used.
(message has no fields)
RequestCancelActivityExecution requests cancellation of an activity execution. Cancellation is cooperative: this call records the request, but the activity must detect and acknowledge it for the activity to reach CANCELED status. The cancellation signal is delivered via `cancel_requested` in the heartbeat response; SDKs surface this via language-idiomatic mechanisms (context cancellation, exceptions, abort signals).
Activity run ID, targets the latest run if run_id is empty.
The identity of the worker/client.
Used to de-dupe cancellation requests.
Reason for requesting the cancellation, recorded and available via the PollActivityExecution API. Not propagated to a worker if an activity attempt is currently running.
(message has no fields)
RequestCancelNexusOperationExecution requests cancellation of a Nexus operation. Requesting to cancel an operation does not automatically transition the operation to canceled status. The operation will only transition to canceled status if it supports cancellation and the handler processes the cancellation request.
Operation run ID, targets the latest run if empty.
The identity of the client who initiated this request.
Used to de-dupe cancellation requests.
Reason for requesting the cancellation, recorded and available via the DescribeNexusOperationExecution API.
(message has no fields)
RequestCancelWorkflowExecution is called by workers when they want to request cancellation of a workflow execution. This results in a new `WORKFLOW_EXECUTION_CANCEL_REQUESTED` event being written to the workflow history and a new workflow task created for the workflow. It returns success if the requested workflow is already closed. It fails with 'NotFound' if the requested workflow doesn't exist.
The identity of the worker/client
Used to de-dupe cancellation requests
If set, this call will error if the most recent (if no run id is set on `workflow_execution`), or specified (if it is) workflow execution is not part of the same execution chain as this id.
Reason for requesting the cancellation
Links to be associated with the WorkflowExecutionCanceled event.
(message has no fields)
ResetActivity resets the execution of an activity specified by its ID or type. If there are multiple pending activities of the provided type - all of them will be reset. Resetting an activity means: * number of attempts will be reset to 0. * activity timeouts will be reset. * if the activity is waiting for retry, and it is not paused or 'keep_paused' is not provided: it will be scheduled immediately (* see 'jitter' flag), Flags: 'jitter': the activity will be scheduled at a random time within the jitter duration. If the activity currently paused it will be unpaused, unless 'keep_paused' flag is provided. 'reset_heartbeats': the activity heartbeat timer and heartbeats will be reset. 'keep_paused': if the activity is paused, it will remain paused. Returns a `NotFound` error if there is no pending activity with the provided ID or type. This API will be deprecated soon and replaced with a newer ResetActivityExecution that is better named and structured to work well for standalone activities.
NOTE: keep in sync with temporal.api.batch.v1.BatchOperationResetActivities Deprecated. Use `ResetActivityExecutionRequest`.
Namespace of the workflow which scheduled this activity.
Execution info of the workflow which scheduled this activity
The identity of the client who initiated this request.
either activity id, activity type or update_all must be provided
Only activity with this ID will be reset.
Reset all running activities with of this type.
Reset all running activities.
Indicates that activity should reset heartbeat details. This flag will be applied only to the new instance of the activity.
If activity is paused, it will remain paused after reset
If set, and activity is in backoff, the activity will start at a random time within the specified jitter duration. (unless it is paused and keep_paused is set)
If set, the activity options will be restored to the defaults. Default options are then options activity was created with. They are part of the first schedule event.
Deprecated. Use `ResetActivityExecutionRequest`.
(message has no fields)
ResetActivityExecution resets the execution of an activity specified by its ID. This API can be used to target a workflow activity or a standalone activity. Resetting an activity means: * number of attempts will be reset to 0. * activity timeouts will be reset. * if the activity is waiting for retry, and it is not paused or 'keep_paused' is not provided: it will be scheduled immediately (* see 'jitter' flag) Returns a `NotFound` error if there is no pending activity with the provided ID or type.
Namespace of the workflow which scheduled this activity.
If provided, targets a workflow activity for the given workflow ID. If empty, targets a standalone activity.
The ID of the activity to target.
Run ID of the workflow or standalone activity.
The identity of the client who initiated this request.
Indicates that activity should reset heartbeat details. This flag will be applied only to the new instance of the activity.
If activity is paused, it will remain paused after reset
If set, and activity is in backoff, the activity will start at a random time within the specified jitter duration. (unless it is paused and keep_paused is set)
If set, the activity options will be restored to the defaults. Default options are then options activity was created with. They are part of the first schedule event.
Resource ID for routing. Contains "workflow:{workflow_id}" for workflow activities or "activity:{activity_id}" for standalone activities.
(message has no fields)
ResetStickyTaskQueue resets the sticky task queue related information in the mutable state of a given workflow. This is prudent for workers to perform if a workflow has been paged out of their cache. Things cleared are: 1. StickyTaskQueue 2. StickyScheduleToStartTimeout When possible, ShutdownWorker should be preferred over ResetStickyTaskQueue (particularly when a worker is shutting down or cycling). (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: We do not expose worker API to HTTP. --)
(message has no fields)
ResetWorkflowExecution will reset an existing workflow execution to a specified `WORKFLOW_TASK_COMPLETED` event (exclusive). It will immediately terminate the current execution instance. "Exclusive" means the identified completed event itself is not replayed in the reset history; the preceding `WORKFLOW_TASK_STARTED` event remains and will be marked as failed immediately, and a new workflow task will be scheduled to retry it.
The workflow to reset. If this contains a run ID then the workflow will be reset back to the provided event ID in that run. Otherwise it will be reset to the provided event ID in the current run. In all cases the current run will be terminated and a new run started.
The id of a `WORKFLOW_TASK_COMPLETED`,`WORKFLOW_TASK_TIMED_OUT`, `WORKFLOW_TASK_FAILED`, or `WORKFLOW_TASK_STARTED` event to reset to.
Used to de-dupe reset requests
Deprecated. Use `options`. Default: RESET_REAPPLY_TYPE_SIGNAL
Event types not to be reapplied
Operations to perform after the workflow has been reset. These operations will be applied to the *new* run of the workflow execution in the order they are provided. All operations are applied to the workflow before the first new workflow task is generated
The identity of the worker/client
RespondActivityTaskFailed is called by workers when processing an activity task fails. For workflow activities, this results in a new `ACTIVITY_TASK_CANCELED` event being written to the workflow history and a new workflow task created for the workflow. Fails with `NotFound` if the task token is no longer valid due to activity timeout, already being completed, or never having existed.
The task token as received in `PollActivityTaskQueueResponse`
Serialized additional information to attach to the cancellation
The identity of the worker/client
Resource ID for routing. Contains the workflow ID or activity ID for standalone activities.
Version info of the worker who processed this task. This message's `build_id` field should always be set by SDKs. Workers opting into versioning will also set the `use_versioning` field to true. See message docstrings for more. Deprecated. Use `deployment_options` instead.
Deployment info of the worker that completed this task. Must be present if user has set `WorkerDeploymentOptions` regardless of versioning being enabled or not. Deprecated. Replaced with `deployment_options`.
Worker deployment options that user has set in the worker.
(message has no fields)
See `RespondActivityTaskCanceled`. This version allows clients to record failures by namespace/workflow id/activity id instead of task token. (-- api-linter: core::0136::prepositions=disabled aip.dev/not-precedent: "By" is used to indicate request type. --)
Namespace of the workflow which scheduled this activity
Id of the workflow which scheduled this activity, leave empty to target a standalone activity
For a workflow activity - the run ID of the workflow which scheduled this activity. For a standalone activity - the run ID of the activity.
Id of the activity to confirm is cancelled
Serialized additional information to attach to the cancellation
The identity of the worker/client
Worker deployment options that user has set in the worker.
Resource ID for routing. Contains "workflow:workflow_id" or "activity:activity_id" for standalone activities.
(message has no fields)
RespondActivityTaskCompleted is called by workers when they successfully complete an activity task. For workflow activities, this results in a new `ACTIVITY_TASK_COMPLETED` event being written to the workflow history and a new workflow task created for the workflow. Fails with `NotFound` if the task token is no longer valid due to activity timeout, already being completed, or never having existed.
The task token as received in `PollActivityTaskQueueResponse`
The result of successfully executing the activity
The identity of the worker/client
Resource ID for routing. Contains the workflow ID or activity ID for standalone activities.
Version info of the worker who processed this task. This message's `build_id` field should always be set by SDKs. Workers opting into versioning will also set the `use_versioning` field to true. See message docstrings for more. Deprecated. Use `deployment_options` instead.
Deployment info of the worker that completed this task. Must be present if user has set `WorkerDeploymentOptions` regardless of versioning being enabled or not. Deprecated. Replaced with `deployment_options`.
Worker deployment options that user has set in the worker.
(message has no fields)
See `RespondActivityTaskCompleted`. This version allows clients to record completions by namespace/workflow id/activity id instead of task token. (-- api-linter: core::0136::prepositions=disabled aip.dev/not-precedent: "By" is used to indicate request type. --)
Namespace of the workflow which scheduled this activity
Id of the workflow which scheduled this activity, leave empty to target a standalone activity
For a workflow activity - the run ID of the workflow which scheduled this activity. For a standalone activity - the run ID of the activity.
Id of the activity to complete
The serialized result of activity execution
The identity of the worker/client
Resource ID for routing. Contains "workflow:workflow_id" or "activity:activity_id" for standalone activities.
(message has no fields)
RespondActivityTaskFailed is called by workers when processing an activity task fails. This results in a new `ACTIVITY_TASK_FAILED` event being written to the workflow history and a new workflow task created for the workflow. Fails with `NotFound` if the task token is no longer valid due to activity timeout, already being completed, or never having existed.
The task token as received in `PollActivityTaskQueueResponse`
Detailed failure information
The identity of the worker/client
Resource ID for routing. Contains the workflow ID or activity ID for standalone activities.
Additional details to be stored as last activity heartbeat
Version info of the worker who processed this task. This message's `build_id` field should always be set by SDKs. Workers opting into versioning will also set the `use_versioning` field to true. See message docstrings for more. Deprecated. Use `deployment_options` instead.
Deployment info of the worker that completed this task. Must be present if user has set `WorkerDeploymentOptions` regardless of versioning being enabled or not. Deprecated. Replaced with `deployment_options`.
Worker deployment options that user has set in the worker.
Server validation failures could include last_heartbeat_details payload is too large, request failure is too large
See `RecordActivityTaskFailed`. This version allows clients to record failures by namespace/workflow id/activity id instead of task token. (-- api-linter: core::0136::prepositions=disabled aip.dev/not-precedent: "By" is used to indicate request type. --)
Namespace of the workflow which scheduled this activity
Id of the workflow which scheduled this activity, leave empty to target a standalone activity
For a workflow activity - the run ID of the workflow which scheduled this activity. For a standalone activity - the run ID of the activity.
Id of the activity to fail
Detailed failure information
The identity of the worker/client
Additional details to be stored as last activity heartbeat
Resource ID for routing. Contains "workflow:workflow_id" or "activity:activity_id" for standalone activities.
Server validation failures could include last_heartbeat_details payload is too large, request failure is too large
RespondNexusTaskCompleted is called by workers to respond to Nexus tasks received via PollNexusTaskQueue. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: We do not expose worker API to HTTP. --)
The identity of the client who initiated this request.
A unique identifier for this task as received via a poll response.
Embedded response to be translated into a frontend response.
Client must forward the poller_group_id received in PollNexusTaskQueueResponse for proper routing of the response.
(message has no fields)
RespondNexusTaskFailed is called by workers to fail Nexus tasks received via PollNexusTaskQueue. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: We do not expose worker API to HTTP. --)
The identity of the client who initiated this request.
A unique identifier for this task.
Deprecated. Use the failure field instead.
The error the handler failed with. Must contain a NexusHandlerFailureInfo object.
Client must forward the poller_group_id received in PollNexusTaskQueueResponse for proper routing of the response.
(message has no fields)
RespondQueryTaskCompleted is called by workers to complete queries which were delivered on the `query` (not `queries`) field of a `PollWorkflowTaskQueueResponse`. Completing the query will unblock the corresponding client call to `QueryWorkflow` and return the query result a response. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: We do not expose worker API to HTTP. --)
The result of the query. Mutually exclusive with `error_message` and `failure`. Set when the query succeeds.
A plain error message that must be set if completed_type is QUERY_RESULT_TYPE_FAILED. SDKs should also fill in the more complete `failure` field to provide the full context and support encryption of failure information. `error_message` will be duplicated if the `failure` field is present to support callers that pre-date the addition of that field, regardless of whether or not a custom failure converter is used. Mutually exclusive with `query_result`. Set when the query fails.
The full reason for this query failure. This field is newer than `error_message` and can be encoded by the SDK's failure converter to support E2E encryption of messages and stack traces. Mutually exclusive with `query_result`. Set when the query fails.
Why did the task fail? It's important to note that many of the variants in this enum cannot apply to worker responses. See the type's doc for more.
Client must forward the poller_group_id received in PollWorkflowTaskQueueResponse for proper routing of the response.
(message has no fields)
RespondWorkflowTaskCompleted is called by workers to successfully complete workflow tasks they received from `PollWorkflowTaskQueue`. Completing a WorkflowTask will write a `WORKFLOW_TASK_COMPLETED` event to the workflow's history, along with events corresponding to whatever commands the SDK generated while executing the task (ex timer started, activity task scheduled, etc). (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: We do not expose worker API to HTTP. --)
The task token as received in `PollWorkflowTaskQueueResponse`
A list of commands generated when driving the workflow code in response to the new task
The identity of the worker/client
May be set by workers to indicate that the worker desires future tasks to be provided with incremental history on a sticky queue.
If set, the worker wishes to immediately receive the next workflow task as a response to this completion. This can save on polling round-trips.
Can be used to *force* creation of a new workflow task, even if no commands have resolved or one would not otherwise have been generated. This is used when the worker knows it is doing something useful, but cannot complete it within the workflow task timeout. Local activities which run for longer than the task timeout being the prime example.
Deprecated. Use `deployment_options` instead. Worker process' unique binary id
Responses to the `queries` field in the task being responded to
Resource ID for routing. Contains the workflow ID from the original task.
Version info of the worker who processed this task. This message's `build_id` field should always be set by SDKs. Workers opting into versioning will also set the `use_versioning` field to true. See message docstrings for more. Deprecated. Use `deployment_options` and `versioning_behavior` instead.
Protocol messages piggybacking on a WFT as a transport
Data the SDK wishes to record for itself, but server need not interpret, and does not directly impact workflow state.
Local usage data collected for metering
All capabilities the SDK supports.
Deployment info of the worker that completed this task. Must be present if user has set `WorkerDeploymentOptions` regardless of versioning being enabled or not. Deprecated. Replaced with `deployment_options`.
Versioning behavior of this workflow execution as set on the worker that completed this task. UNSPECIFIED means versioning is not enabled in the worker.
Worker deployment options that user has set in the worker.
A unique key for this worker instance, used for tracking worker lifecycle. This is guaranteed to be unique, whereas identity is not guaranteed to be unique.
A dedicated per-worker Nexus task queue on which the server sends control tasks (e.g. activity cancellation) to this specific worker instance.
See `RespondWorkflowTaskCompletedResponse::return_new_workflow_task`
See `ScheduleActivityTaskCommandAttributes::request_eager_execution`
If non zero, indicates the server has discarded the workflow task that was being responded to. Will be the event ID of the last workflow task started event in the history before the new workflow task. Server is only expected to discard a workflow task if it could not have modified the workflow state.
RespondWorkflowTaskFailed is called by workers to indicate the processing of a workflow task failed. This results in a `WORKFLOW_TASK_FAILED` event written to the history, and a new workflow task will be scheduled. This API can be used to report unhandled failures resulting from applying the workflow task. Temporal will only append first WorkflowTaskFailed event to the history of workflow execution for consecutive failures. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: We do not expose worker API to HTTP. --)
The task token as received in `PollWorkflowTaskQueueResponse`
Why did the task fail? It's important to note that many of the variants in this enum cannot apply to worker responses. See the type's doc for more.
Failure details
The identity of the worker/client
Deprecated. Use `deployment_options` instead. Worker process' unique binary id
Resource ID for routing. Contains the workflow ID from the original task.
Protocol messages piggybacking on a WFT as a transport
Version info of the worker who processed this task. This message's `build_id` field should always be set by SDKs. Workers opting into versioning will also set the `use_versioning` field to true. See message docstrings for more. Deprecated. Use `deployment_options` instead.
Deployment info of the worker that completed this task. Must be present if user has set `WorkerDeploymentOptions` regardless of versioning being enabled or not. Deprecated. Replaced with `deployment_options`.
Worker deployment options that user has set in the worker.
(message has no fields)
ScanWorkflowExecutions _was_ a visibility API to list large amount of workflow executions in a specific namespace without order. It has since been deprecated in favor of `ListWorkflowExecutions` and rewritten to use `ListWorkflowExecutions` internally. Deprecated: Replaced with `ListWorkflowExecutions`. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: HTTP users should use ListWorkflowExecutions instead. --)
Deprecated: Use with `ListWorkflowExecutions`.
Deprecated: Use with `ListWorkflowExecutions`.
Sets a deployment as the current deployment for its deployment series. Can optionally update the metadata of the deployment as well. Experimental. This API might significantly change or be removed in a future release. Deprecated. Replaced by `SetWorkerDeploymentCurrentVersion`.
[cleanup-wv-pre-release] Pre-release deployment APIs, clean up later
Optional. The identity of the client who initiated this request.
Optional. Use to add or remove user-defined metadata entries. Metadata entries are exposed when describing a deployment. It is a good place for information such as operator name, links to internal deployment pipelines, etc.
[cleanup-wv-pre-release] Pre-release deployment APIs, clean up later
Info of the deployment that was current before executing this operation.
Set/unset the Current Version of a Worker Deployment. Automatically unsets the Ramping Version if it is the Version being set as Current. Experimental. This API might significantly change or be removed in a future release.
Set/unset the Current Version of a Worker Deployment.
Deprecated. Use `build_id`.
The build id of the Version that you want to set as Current. Pass an empty value to set the Current Version to nil. A nil Current Version represents all the unversioned workers (those with `UNVERSIONED` (or unspecified) `WorkerVersioningMode`.)
Optional. This can be the value of conflict_token from a Describe, or another Worker Deployment API. Passing a non-nil conflict token will cause this request to fail if the Deployment's configuration has been modified between the API call that generated the token and this one.
Optional. The identity of the client who initiated this request.
Optional. By default this request would be rejected if not all the expected Task Queues are being polled by the new Version, to protect against accidental removal of Task Queues, or worker health issues. Pass `true` here to bypass this protection. The set of expected Task Queues is the set of all the Task Queues that were ever poller by the existing Current Version of the Deployment, with the following exclusions: - Task Queues that are not used anymore (inferred by having empty backlog and a task add_rate of 0.) - Task Queues that are moved to another Worker Deployment (inferred by the Task Queue having a different Current Version than the Current Version of this deployment.) WARNING: Do not set this flag unless you are sure that the missing task queue pollers are not needed. If the request is unexpectedly rejected due to missing pollers, then that means the pollers have not reached to the server yet. Only set this if you expect those pollers to never arrive.
Optional. By default this request will be rejected if no pollers have been seen for the proposed Current Version, in order to protect users from routing tasks to pollers that do not exist, leading to possible timeouts. Pass `true` here to bypass this protection.
This value is returned so that it can be optionally passed to APIs that write to the Worker Deployment state to ensure that the state did not change between this API call and a future write.
Deprecated. Use `previous_deployment_version`.
The version that was current before executing this operation. Deprecated in favor of idempotency of the API. Use `DescribeWorkerDeployment` to get the Current version info before calling this API. By passing the `conflict_token` got from the `DescribeWorkerDeployment` call to this API you can ensure there is no interfering changes between the two calls.
Set/unset the ManagerIdentity of a Worker Deployment. Experimental. This API might significantly change or be removed in a future release.
Update the ManagerIdentity of a Worker Deployment.
Arbitrary value for `manager_identity`. Empty will unset the field.
True will set `manager_identity` to `identity`.
Optional. This can be the value of conflict_token from a Describe, or another Worker Deployment API. Passing a non-nil conflict token will cause this request to fail if the Deployment's configuration has been modified between the API call that generated the token and this one.
Required. The identity of the client who initiated this request.
This value is returned so that it can be optionally passed to APIs that write to the Worker Deployment state to ensure that the state did not change between this API call and a future write.
What the `manager_identity` field was before this change. Deprecated in favor of idempotency of the API. Use `DescribeWorkerDeployment` to get the manager identity before calling this API. By passing the `conflict_token` got from the `DescribeWorkerDeployment` call to this API you can ensure there is no interfering changes between the two calls.
Set/unset the Ramping Version of a Worker Deployment and its ramp percentage. Can be used for gradual ramp to unversioned workers too. Experimental. This API might significantly change or be removed in a future release.
Set/unset the Ramping Version of a Worker Deployment and its ramp percentage.
Deprecated. Use `build_id`.
The build id of the Version that you want to ramp traffic to. Pass an empty value to set the Ramping Version to nil. A nil Ramping Version represents all the unversioned workers (those with `UNVERSIONED` (or unspecified) `WorkerVersioningMode`.)
Ramp percentage to set. Valid range: [0,100].
Optional. This can be the value of conflict_token from a Describe, or another Worker Deployment API. Passing a non-nil conflict token will cause this request to fail if the Deployment's configuration has been modified between the API call that generated the token and this one.
Optional. The identity of the client who initiated this request.
Optional. By default this request would be rejected if not all the expected Task Queues are being polled by the new Version, to protect against accidental removal of Task Queues, or worker health issues. Pass `true` here to bypass this protection. The set of expected Task Queues equals to all the Task Queues ever polled from the existing Current Version of the Deployment, with the following exclusions: - Task Queues that are not used anymore (inferred by having empty backlog and a task add_rate of 0.) - Task Queues that are moved to another Worker Deployment (inferred by the Task Queue having a different Current Version than the Current Version of this deployment.) WARNING: Do not set this flag unless you are sure that the missing task queue poller are not needed. If the request is unexpectedly rejected due to missing pollers, then that means the pollers have not reached to the server yet. Only set this if you expect those pollers to never arrive. Note: this check only happens when the ramping version is about to change, not every time that the percentage changes. Also note that the check is against the deployment's Current Version, not the previous Ramping Version.
Optional. By default this request will be rejected if no pollers have been seen for the proposed Current Version, in order to protect users from routing tasks to pollers that do not exist, leading to possible timeouts. Pass `true` here to bypass this protection.
This value is returned so that it can be optionally passed to APIs that write to the Worker Deployment state to ensure that the state did not change between this API call and a future write.
Deprecated. Use `previous_deployment_version`.
The version that was ramping before executing this operation. Deprecated in favor of idempotency of the API. Use `DescribeWorkerDeployment` to get the Ramping version info before calling this API. By passing the `conflict_token` got from the `DescribeWorkerDeployment` call to this API you can ensure there is no interfering changes between the two calls.
The ramping version percentage before executing this operation. Deprecated in favor of idempotency of the API. Use `DescribeWorkerDeployment` to get the Ramping version info before calling this API. By passing the `conflict_token` got from the `DescribeWorkerDeployment` call to this API you can ensure there is no interfering changes between the two calls.
ShutdownWorker is used to indicate that the given sticky task queue is no longer being polled by its worker. Following the completion of ShutdownWorker, newly-added workflow tasks will instead be placed in the normal task queue, eligible for any worker to pick up. ShutdownWorker should be called by workers while shutting down, after they've shut down their pollers. If another sticky poll request is issued, the sticky task queue will be revived. As of Temporal Server v1.25.0, ShutdownWorker hasn't yet been implemented. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: We do not expose worker API to HTTP. --)
sticky_task_queue may not always be populated. We want to ensure all workers send a shutdown request to update worker state for heartbeating, as well as cancel pending poll calls early, instead of waiting for timeouts.
Technically this is also sent in the WorkerHeartbeat, but since worker heartbeating can be turned off, this needs to be a separate, top-level field.
Task queue name the worker is polling on. This allows server to cancel all outstanding poll RPC calls from SDK. This avoids a race condition that can lead to tasks being lost.
Task queue types that help server cancel outstanding poll RPC calls from SDK. This avoids a race condition that can lead to tasks being lost.
(message has no fields)
SignalWithStartWorkflowExecution is used to ensure a signal is sent to a workflow, even if it isn't yet started. If the workflow is running, a `WORKFLOW_EXECUTION_SIGNALED` event is recorded in the history and a workflow task is generated. If the workflow is not running or not found, then the workflow is created with `WORKFLOW_EXECUTION_STARTED` and `WORKFLOW_EXECUTION_SIGNALED` events in its history, and a workflow task is generated. (-- api-linter: core::0136::prepositions=disabled aip.dev/not-precedent: "With" is used to indicate combined operation. --)
The task queue to start this workflow on, if it will be started
Serialized arguments to the workflow. These are passed 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
The identity of the worker/client
Used to de-dupe signal w/ start requests
Defines whether to allow re-using the workflow id from a previously *closed* workflow. The default policy is WORKFLOW_ID_REUSE_POLICY_ALLOW_DUPLICATE. See `workflow_id_reuse_policy` for handling a workflow id duplication with a *running* workflow.
Defines how to resolve a workflow id conflict with a *running* workflow. The default policy is WORKFLOW_ID_CONFLICT_POLICY_USE_EXISTING. Note that WORKFLOW_ID_CONFLICT_POLICY_FAIL is an invalid option. See `workflow_id_reuse_policy` for handling a workflow id duplication with a *closed* workflow.
The workflow author-defined name of the signal to send to the workflow
Serialized value(s) to provide with the signal
Deprecated.
Retry policy for the workflow
See https://docs.temporal.io/docs/content/what-is-a-temporal-cron-job/
Time to wait before dispatching the first workflow task. Cannot be used with `cron_schedule`. Note that the signal will be delivered with the first workflow task. If the workflow gets another SignalWithStartWorkflow before the delay a workflow task will be dispatched immediately and the rest of the delay period will be ignored, even if that request also had a delay. Signal via SignalWorkflowExecution will not unblock the workflow.
Metadata on the workflow if it is started. This is carried over to the WorkflowExecutionInfo for use by user interfaces to display the fixed as-of-start summary and details of the workflow.
Links to be associated with the WorkflowExecutionStarted and WorkflowExecutionSignaled events.
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
Time-skipping configuration. If not set, time skipping is disabled.
The run id of the workflow that was started - or just signaled, if it was already running.
If true, a new workflow was started.
Link to be associated with the WorkflowExecutionSignaled event. Added on the response to propagate the backlink. Available from Temporal server 1.31 and up.
SignalWorkflowExecution is used to send a signal to a running workflow execution. This results in a `WORKFLOW_EXECUTION_SIGNALED` event recorded in the history and a workflow task being created for the execution.
Keep the parameters in sync with: - temporal.api.batch.v1.BatchOperationSignal. - temporal.api.workflow.v1.PostResetOperation.SignalWorkflow.
The workflow author-defined name of the signal to send to the workflow
Serialized value(s) to provide with the signal
The identity of the worker/client
Used to de-dupe sent signals
Deprecated.
Headers that are passed with the signal to the processing workflow. These can include things like auth or tracing tokens.
Links to be associated with the WorkflowExecutionSignaled event.
Link to be associated with the WorkflowExecutionSignaled event. Added on the response to propagate the backlink. Available from Temporal server 1.31 and up.
StartActivityExecution starts a new activity execution. Returns an `ActivityExecutionAlreadyStarted` error if an instance already exists with same activity ID in this namespace unless permitted by the specified ID conflict policy.
The identity of the client who initiated this request
A unique identifier for this start request. Typically UUIDv4.
Identifier for this activity. Required. This identifier should be meaningful in the user's own system. It must be unique among activities in the same namespace, subject to the rules imposed by id_reuse_policy and id_conflict_policy.
The type of the activity, a string that corresponds to a registered activity on a worker.
Task queue to schedule this activity on.
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` 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 retry policy for the activity. Will never exceed `schedule_to_close_timeout`.
Serialized arguments to the activity. These are passed as arguments to the activity function.
Defines whether to allow re-using the activity id from a previously *closed* activity. The default policy is ACTIVITY_ID_REUSE_POLICY_ALLOW_DUPLICATE.
Defines how to resolve an activity id conflict with a *running* activity. The default policy is ACTIVITY_ID_CONFLICT_POLICY_FAIL.
Search attributes for indexing.
Header for context propagation and tracing purposes.
Metadata for use by user interfaces to display the fixed as-of-start summary and details of the activity.
Priority metadata.
Callbacks to be called by the server when this activity reaches a terminal state. Callback addresses must be whitelisted in the server's dynamic configuration.
Links to be associated with the activity. Callbacks may also have associated links; links already included with a callback should not be duplicated here.
Options for handling conflicts when using ACTIVITY_ID_CONFLICT_POLICY_USE_EXISTING.
Time to wait before dispatching the first activity task. This delay is not applied to retry attempts.
The run ID of the activity that was started - or used (via ACTIVITY_ID_CONFLICT_POLICY_USE_EXISTING).
If true, a new activity was started.
Link to the started activity.
StartBatchOperation starts a new batch operation
Namespace that contains the batch operation
Visibility query defines the the group of workflow to apply the batch operation This field and `executions` are mutually exclusive
Job ID defines the unique ID for the batch job
Reason to perform the batch operation
Executions to apply the batch operation This field and `visibility_query` are mutually exclusive
Limit for the number of operations processed per second within this batch. Its purpose is to reduce the stress on the system caused by batch operations, which helps to prevent system overload and minimize potential delays in executing ongoing tasks for user workers. Note that when no explicit limit is provided, the server will operate according to its limit defined by the dynamic configuration key `worker.batcherRPS`. This also applies if the value in this field exceeds the server's configured limit.
Operation input
(message has no fields)
StartNexusOperationExecution starts a new Nexus operation. Returns a `NexusOperationExecutionAlreadyStarted` error if an instance already exists with same operation ID in this namespace unless permitted by the specified ID conflict policy.
The identity of the client who initiated this request.
A unique identifier for this caller-side start request. Typically UUIDv4. StartOperation requests sent to the handler will use a server-generated request ID.
Identifier for this operation. This is a caller-side ID, distinct from any internal operation identifiers generated by the handler. Must be unique among operations in the same namespace, subject to the rules imposed by id_reuse_policy and id_conflict_policy.
Endpoint name, resolved to a URL via the cluster's endpoint registry.
Service name.
Operation name.
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. --)
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 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. --)
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. 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. --)
Serialized input to the operation. Passed as the request payload.
Defines whether to allow re-using the operation id from a previously *closed* operation. The default policy is NEXUS_OPERATION_ID_REUSE_POLICY_ALLOW_DUPLICATE.
Defines how to resolve an operation id conflict with a *running* operation. The default policy is NEXUS_OPERATION_ID_CONFLICT_POLICY_FAIL.
Search attributes for indexing.
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.
Metadata for use by user interfaces to display the fixed as-of-start summary and details of the operation.
The run ID of the operation that was started - or used (via NEXUS_OPERATION_ID_CONFLICT_POLICY_USE_EXISTING).
If true, a new operation was started.
StartWorkflowExecution starts a new workflow execution. It will create the execution with a `WORKFLOW_EXECUTION_STARTED` event in its history and also schedule the first workflow task. Returns `WorkflowExecutionAlreadyStarted`, if an instance already exists with same workflow id.
StopBatchOperation stops a batch operation
Namespace that contains the batch operation
Batch job id
Reason to stop a batch operation
Identity of the operator
(message has no fields)
TerminateActivityExecution terminates an existing activity execution immediately. Termination does not reach the worker and the activity code cannot react to it. A terminated activity may have a running attempt.
Activity run ID, targets the latest run if run_id is empty.
The identity of the worker/client.
Used to de-dupe termination requests.
Reason for requesting the termination, recorded in in the activity's result failure outcome.
(message has no fields)
TerminateNexusOperationExecution terminates an existing Nexus operation immediately. Termination happens immediately and the operation handler cannot react to it. A terminated operation will have its outcome set to a failure with a termination reason.
Operation run ID, targets the latest run if empty.
The identity of the client who initiated this request.
Used to de-dupe termination requests.
Reason for requesting the termination, recorded in the operation's result failure outcome.
(message has no fields)
TerminateWorkflowExecution terminates an existing workflow execution by recording a `WORKFLOW_EXECUTION_TERMINATED` event in the history and immediately terminating the execution instance.
Serialized additional information to attach to the termination event
The identity of the worker/client
If set, this call will error if the most recent (if no run id is set on `workflow_execution`), or specified (if it is) workflow execution is not part of the same execution chain as this id.
Links to be associated with the WorkflowExecutionTerminated event.
(message has no fields)
TriggerWorkflowRule allows to: * trigger existing rule for a specific workflow execution; * trigger rule for a specific workflow execution without creating a rule; This is useful for one-off operations.
Execution info of the workflow which scheduled this activity
Either provide id of existing rule, or rule specification
Note: Rule ID and expiration date are not used in the trigger request.
The identity of the client who initiated this request
True is the rule was applied, based on the rule conditions (predicate/visibility_query).
UnpauseActivity unpauses the execution of an activity specified by its ID or type. If there are multiple pending activities of the provided type - all of them will be unpaused. If activity is not paused, this call will have no effect. If the activity was paused while waiting for retry, it will be scheduled immediately (* see 'jitter' flag). Once the activity is unpaused, all timeout timers will be regenerated. Flags: 'jitter': the activity will be scheduled at a random time within the jitter duration. 'reset_attempts': the number of attempts will be reset. 'reset_heartbeat': the activity heartbeat timer and heartbeats will be reset. Returns a `NotFound` error if there is no pending activity with the provided ID or type This API will be deprecated soon and replaced with a newer UnpauseActivityExecution that is better named and structured to work well for standalone activities.
Deprecated. Use `UnpauseActivityExecutionRequest`.
Namespace of the workflow which scheduled this activity.
Execution info of the workflow which scheduled this activity
The identity of the client who initiated this request.
either activity id or activity type must be provided
Only the activity with this ID will be unpaused.
Unpause all running activities with of this type.
Unpause all running activities.
Providing this flag will also reset the number of attempts.
Providing this flag will also reset the heartbeat details.
If set, the activity will start at a random time within the specified jitter duration.
Deprecated. Use `UnpauseActivityExecutionResponse`.
(message has no fields)
UnpauseActivityExecution unpauses the execution of an activity specified by its ID. This API can be used to target a workflow activity or a standalone activity. If activity is not paused, this call will have no effect. If the activity was paused while waiting for retry, it will be scheduled immediately (* see 'jitter' flag). Once the activity is unpaused, all timeout timers will be regenerated. Returns a `NotFound` error if there is no pending activity with the provided ID
Namespace of the workflow which scheduled this activity.
If provided, targets a workflow activity for the given workflow ID. If empty, targets a standalone activity.
The ID of the activity to target.
Run ID of the workflow or standalone activity.
The identity of the client who initiated this request.
Providing this flag will also reset the number of attempts.
Providing this flag will also reset the heartbeat details.
Reason to unpause the activity.
If set, the activity will start at a random time within the specified jitter duration.
Resource ID for routing. Contains "workflow:{workflow_id}" for workflow activities or "activity:{activity_id}" for standalone activities.
(message has no fields)
Note: This is an experimental API and the behavior may change in a future release. UnpauseWorkflowExecution unpauses a previously paused workflow execution specified in the request. Unpausing a workflow execution results in - The workflow execution status changes to `RUNNING` and a new WORKFLOW_EXECUTION_UNPAUSED event is added to the history - Workflow tasks and activity tasks are resumed.
Namespace of the workflow to unpause.
ID of the workflow execution to be paused. Required.
Run ID of the workflow execution to be paused. Optional. If not provided, the current run of the workflow will be paused.
The identity of the client who initiated this request.
Reason to unpause the workflow execution.
A unique identifier for this unpause request for idempotence. Typically UUIDv4.
Response to a successful UnpauseWorkflowExecution request.
(message has no fields)
UpdateActivityExecutionOptions is called by the client to update the options of an activity by its ID. This API can be used to target a workflow activity or a standalone activity.
Namespace of the workflow which scheduled this activity
If provided, targets a workflow activity for the given workflow ID. If empty, targets a standalone activity.
The ID of the activity to target.
Run ID of the workflow or standalone activity.
The identity of the client who initiated this request
Activity options. Partial updates are accepted and controlled by update_mask
Controls which fields from `activity_options` will be applied
If set, the activity options will be restored to the default. Default options are then options activity was created with. They are part of the first schedule event. This flag cannot be combined with any other option; if you supply restore_original together with other options, the request will be rejected.
Resource ID for routing. Contains "workflow:{workflow_id}" for workflow activities or "activity:{activity_id}" for standalone activities.
Activity options after an update
UpdateActivityOptions is called by the client to update the options of an activity by its ID or type. If there are multiple pending activities of the provided type - all of them will be updated. This API will be deprecated soon and replaced with a newer UpdateActivityExecutionOptions that is better named and structured to work well for standalone activities.
NOTE: keep in sync with temporal.api.batch.v1.BatchOperationUpdateActivityOptions Deprecated. Use `UpdateActivityExecutionOptionsRequest`.
Namespace of the workflow which scheduled this activity
Execution info of the workflow which scheduled this activity
The identity of the client who initiated this request
Activity options. Partial updates are accepted and controlled by update_mask
Controls which fields from `activity_options` will be applied
either activity id, activity type or update_all must be provided
Only activity with this ID will be updated.
Update all running activities of this type.
Update all running activities.
If set, the activity options will be restored to the default. Default options are then options activity was created with. They are part of the first schedule event. This flag cannot be combined with any other option; if you supply restore_original together with other options, the request will be rejected.
Deprecated. Use `UpdateActivityExecutionOptionsResponse`.
Activity options after an update
UpdateNamespace is used to update the information and configuration of a registered namespace.
promote local namespace to global namespace. Ignored if namespace is already global namespace.
Changes the configuration or state of an existing schedule.
The namespace of the schedule to update.
The id of the schedule to update.
The new schedule. The four main fields of the schedule (spec, action, policies, state) are replaced completely by the values in this message.
This can be the value of conflict_token from a DescribeScheduleResponse, which will cause this request to fail if the schedule has been modified between the Describe and this Update. If missing, the schedule will be updated unconditionally.
The identity of the client who initiated this request.
A unique identifier for this update request for idempotence. Typically UUIDv4.
Schedule search attributes to be updated. Do not set this field if you do not want to update the search attributes. A non-null empty object will set the search attributes to an empty map. Note: you cannot only update the search attributes with `UpdateScheduleRequest`, you must also set the `schedule` field; otherwise, it will unset the schedule.
Schedule memo to replace. If set, replaces the entire memo. Do not set this field if you do not want to update the memo. A non-null empty object will clear the memo.
(message has no fields)
Updates task queue configuration. For the overall queue rate limit: the rate limit set by this api overrides the worker-set rate limit, which uncouples the rate limit from the worker lifecycle. If the overall queue rate limit is unset, the worker-set rate limit takes effect.
Selects the task queue to update.
Update to queue-wide rate limit. If not set, this configuration is unchanged. NOTE: A limit set by the worker is overriden; and restored again when reset. If the `rate_limit` field in the `RateLimitUpdate` is missing, remove the existing rate limit.
Update to the default fairness key rate limit. If not set, this configuration is unchanged. If the `rate_limit` field in the `RateLimitUpdate` is missing, remove the existing rate limit.
If set, overrides the fairness weight for each specified fairness key. Fairness keys not listed in this map will keep their existing overrides (if any).
If set, removes any existing fairness weight overrides for each specified fairness key. Fairness weights for corresponding keys fall back to the values set during task creation (if any), or to the default weight of 1.0.
Deprecated. Use `UpdateWorkerVersioningRules`. Will be removed in server version v1.32.0. Allows users to specify sets of worker build id versions on a per task queue basis. Versions are ordered, and may be either compatible with some extant version, or a new incompatible version, forming sets of ids which are incompatible with each other, but whose contained members are compatible with one another. A single build id may be mapped to multiple task queues using this API for cases where a single process hosts multiple workers. To query which workers can be retired, use the `GetWorkerTaskReachability` API. NOTE: The number of task queues mapped to a single build id is limited by the `limit.taskQueuesPerBuildId` (default is 20), if this limit is exceeded this API will error with a FailedPrecondition. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: We do yet expose versioning API to HTTP. --)
[cleanup-wv-pre-release]
Must be set, the task queue to apply changes to. Because all workers on a given task queue must have the same set of workflow & activity implementations, there is no reason to specify a task queue type here.
A new build id. This operation will create a new set which will be the new overall default version for the queue, with this id as its only member. This new set is incompatible with all previous sets/versions. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: In makes perfect sense here. --)
Adds a new id to an existing compatible set, see sub-message definition for more.
Promote an existing set to be the current default (if it isn't already) by targeting an existing build id within it. This field's value is the extant build id. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: Names are hard. --)
Promote an existing build id within some set to be the current default for that set. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: Within makes perfect sense here. --)
Merge two existing sets together, thus declaring all build IDs in both sets compatible with one another. The primary set's default will become the default for the merged set. This is useful if you've accidentally declared a new ID as incompatible you meant to declare as compatible. The unusual case of incomplete replication during failover could also result in a split set, which this operation can repair.
[cleanup-wv-pre-release]
(message has no fields)
UpdateWorkerConfig updates the worker configuration of one or more workers. Can be used to partially update the worker configuration. Can be used to update the configuration of multiple workers.
Namespace this worker belongs to.
The identity of the client who initiated this request.
Reason for sending worker command, can be used for audit purpose.
Partial updates are accepted and controlled by update_mask. The worker configuration to set.
Controls which fields from `worker_config` will be applied
Defines which workers should receive this command.
Resource ID for routing. Contains the worker grouping key.
The worker configuration. Will be returned if the command was sent to a single worker.
Updates the compute config attached to a Worker Deployment Version. Experimental. This API might significantly change or be removed in a future release.
Used to update the compute config of a Worker Deployment Version.
Required.
Optional. Contains the compute config scaling groups to add or update for the Worker Deployment.
Optional. Contains the compute config scaling groups to remove from the Worker Deployment.
Optional. The identity of the client who initiated this request.
A unique identifier for this create request for idempotence. Typically UUIDv4. If a second request with the same ID is recieved, it is considered a successful no-op. Retrying with a different request ID for the same deployment name + build ID is an error.
(message has no fields)
Updates the user-given metadata attached to a Worker Deployment Version. Experimental. This API might significantly change or be removed in a future release.
Used to update the user-defined metadata of a Worker Deployment Version.
Deprecated. Use `deployment_version`.
Required.
List of keys to remove from the metadata.
Optional. The identity of the client who initiated this request.
Full metadata after performing the update.
Use this API to manage Worker Versioning Rules for a given Task Queue. There are two types of rules: Build ID Assignment rules and Compatible Build ID Redirect rules. Assignment rules determine how to assign new executions to a Build IDs. Their primary use case is to specify the latest Build ID but they have powerful features for gradual rollout of a new Build ID. Once a workflow execution is assigned to a Build ID and it completes its first Workflow Task, the workflow stays on the assigned Build ID regardless of changes in assignment rules. This eliminates the need for compatibility between versions when you only care about using the new version for new workflows and let existing workflows finish in their own version. Activities, Child Workflows and Continue-as-New executions have the option to inherit the Build ID of their parent/previous workflow or use the latest assignment rules to independently select a Build ID. Redirect rules should only be used when you want to move workflows and activities assigned to one Build ID (source) to another compatible Build ID (target). You are responsible to make sure the target Build ID of a redirect rule is able to process event histories made by the source Build ID by using [Patching](https://docs.temporal.io/workflows#patching) or other means. Will be removed in server version v1.32.0. (-- api-linter: core::0127::http-annotation=disabled aip.dev/not-precedent: We do yet expose versioning API to HTTP. --)
(-- api-linter: core::0134::request-mask-required=disabled aip.dev/not-precedent: UpdateNamespace RPC doesn't follow Google API format. --) (-- api-linter: core::0134::request-resource-required=disabled aip.dev/not-precedent: GetWorkerBuildIdCompatibilityRequest RPC doesn't follow Google API format. --) [cleanup-wv-pre-release]
A valid conflict_token can be taken from the previous ListWorkerVersioningRulesResponse or UpdateWorkerVersioningRulesResponse. An invalid token will cause this request to fail, ensuring that if the rules for this Task Queue have been modified between the previous and current operation, the request will fail instead of causing an unpredictable mutation.
[cleanup-wv-pre-release]
This value can be passed back to UpdateWorkerVersioningRulesRequest to ensure that the rules were not modified between the two updates, which could lead to lost updates and other confusion.
Invokes the specified Update function on user Workflow code.
UpdateWorkflowExecutionOptions partially updates the WorkflowExecutionOptions of an existing workflow execution.
Keep the parameters in sync with: - temporal.api.batch.v1.BatchOperationUpdateWorkflowExecutionOptions. - temporal.api.workflow.v1.PostResetOperation.UpdateWorkflowOptions.
The namespace name of the target Workflow.
The target Workflow Id and (optionally) a specific Run Id thereof. (-- api-linter: core::0203::optional=disabled aip.dev/not-precedent: false positive triggered by the word "optional" --)
Workflow Execution options. 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.
Optional. The identity of the client who initiated this request.
Workflow Execution options after update.
The Workflow Execution time when the options were updated. When time skipping is enabled, this is the workflow's virtual time rather than wall-clock time.
Validates the compute config without attaching it to a Worker Deployment Version. Experimental. This API might significantly change or be removed in a future release.
Used to validate the compute config without attaching it to a Worker Deployment Version.
Required.
Optional. Contains the compute config scaling groups to add or update for the Worker Deployment.
Optional. Contains the compute config scaling groups to remove from the Worker Deployment.
Optional. The identity of the client who initiated this request.
(message has no fields)
Used in:
Used in:
Used in:
Used in:
Used as response type in: WorkflowService.DescribeNamespace
Used as field type in:
Contains the historical state of failover_versions for the cluster, truncated to contain only the last N states to ensure that the list does not grow unbounded.
The initial info that client should use for poller group assignment. This information is updated through poll response. Client is supposed to use the info received in the latest poll response.
Used in:
The effective rate limit for the task queue.
Source of the RateLimit Configuration,which can be one of the following values: - SOURCE_API: The rate limit that is set via the TaskQueueConfig api. - SOURCE_WORKER: The rate limit is the value set using the workerOptions in TaskQueueActivitiesPerSecond. - SOURCE_SYSTEM: The rate limit is the default value set by the system
(-- api-linter: core::0123::resource-annotation=disabled --)
Used in:
Only set if `report_task_queue_stats` is set on the request.
Task queue stats breakdown by priority key. Only contains actively used priority keys. Only set if `report_task_queue_stats` is set to true in the request. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "by" is used to clarify the key. --)
Used in:
Additional restrictions: - setting `cron_schedule` is invalid - setting `request_eager_execution` is invalid - setting `workflow_start_delay` is invalid
Additional restrictions: - setting `first_execution_run_id` is invalid - setting `workflow_execution.run_id` is invalid
Used in:
System capability details.
Used in:
True if signal and query headers are supported.
True if internal errors are differentiated from other types of errors for purposes of retrying non-internal errors. When unset/false, clients retry all failures. When true, clients should only retry non-internal errors.
True if RespondActivityTaskFailed API supports including heartbeat details
Supports scheduled workflow features.
True if server uses protos that include temporal.api.failure.v1.Failure.encoded_attributes
True if server supports dispatching Workflow and Activity tasks based on a worker's build_id (see: https://github.com/temporalio/proposals/blob/a123af3b559f43db16ea6dd31870bfb754c4dc5e/versioning/worker-versions.md)
True if server supports upserting workflow memo
True if server supports eager workflow task dispatching for the StartWorkflowExecution API
True if the server knows about the sdk metadata field on WFT completions and will record it in history
True if the server supports count group by execution status (-- api-linter: core::0140::prepositions=disabled --)
True if the server supports Nexus operations. This flag is dependent both on server version and for Nexus to be enabled via server configuration.
True if the server supports server-scaled deployments. This flag is dependent both on server version and for server-scaled deployments to be enabled via server configuration.
(-- api-linter: core::0123::resource-annotation=disabled --) A subset of WorkerDeploymentInfo
Used in:
Summary of the version that was added most recently in the Worker Deployment.
Summary of the current version of the Worker Deployment.
Summary of the ramping version of the Worker Deployment.
Used as response type in: WorkflowService.PollActivityTaskQueue
Used as field type in:
A unique identifier for this task
The namespace of the activity. If this is a workflow activity then this is the namespace of the workflow also. If this is a standalone activity then the name of this field is misleading, but retained for compatibility with workflow activities.
Type of the requesting workflow (if this is a workflow activity).
Execution info of the requesting workflow (if this is a workflow activity)
The autogenerated or user specified identifier of this activity. Can be used to complete the activity via `RespondActivityTaskCompletedById`. May be re-used as long as the last usage has resolved, but unique IDs for every activity invocation is a good idea. Note that only a workflow activity ID may be autogenerated.
Headers specified by the scheduling workflow. Commonly used to propagate contextual info from the workflow to its activities. For example, tracing contexts.
Arguments to the activity invocation
Details of the last heartbeat that was recorded for this activity as of the time this task was delivered.
When was this task first scheduled
When was this task attempt scheduled
When was this task started (this attempt)
Starting at 1, the number of attempts to perform this activity
First scheduled -> final result reported timeout (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)
Current attempt start -> final result reported timeout (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)
Window within which the activity must report a heartbeat, or be timed out.
This is the retry policy the service uses which may be different from the one provided (or not) during activity scheduling. The service can override the provided one if some values are not specified or exceed configured system limits.
Server-advised information the SDK may use to adjust its poller count.
Priority metadata
The run ID of the activity execution, only set for standalone activities.
The weighted list of poller groups IDs that client should use for future polls to this task queue. Client is expected to: 1. Maintain minimum number of pollers no less than the number of groups. 2. Try to assign the next poll to a group without any pending polls, 3. If every group has some pending polls, assign the next poll to a group randomly according to the weights.
Used as response type in: WorkflowService.PollWorkflowTaskQueue
Used as field type in: ,
A unique identifier for this task
The last workflow task started event which was processed by some worker for this execution. Will be zero if no task has ever started.
The id of the most recent workflow task started event, which will have been generated as a result of this poll request being served. Will be zero if the task does not contain any events which would advance history (no new WFT started). Currently this can happen for queries.
Starting at 1, the number of attempts to complete this task by any worker.
A hint that there are more tasks already present in this task queue partition. Can be used to prioritize draining a sticky queue. Specifically, the returned number is the number of tasks remaining in the in-memory buffer for this partition, which is currently capped at 1000. Because sticky queues only have one partition, this number is more useful when draining them. Normal queues, typically having more than one partition, will return a number representing only some portion of the overall backlog. Subsequent RPCs may not hit the same partition as this call.
The history for this workflow, which will either be complete or partial. Partial histories are sent to workers who have signaled that they are using a sticky queue when completing a workflow task.
Will be set if there are more history events than were included in this response. Such events should be fetched via `GetWorkflowExecutionHistory`.
Legacy queries appear in this field. The query must be responded to via `RespondQueryTaskCompleted`. If the workflow is already closed (queries are permitted on closed workflows) then the `history` field will be populated with the entire history. It may also be populated if this task originates on a non-sticky queue.
The task queue this task originated from, which will always be the original non-sticky name for the queue, even if this response came from polling a sticky queue.
When this task was scheduled by the server
When the current workflow task started event was generated, meaning the current attempt.
Queries that should be executed after applying the history in this task. Responses should be attached to `RespondWorkflowTaskCompletedRequest::query_results`
Protocol messages piggybacking on a WFT as a transport
Server-advised information the SDK may use to adjust its poller count.
This poller group ID identifies the owner of the workflow task awaiting for query response. Corresponding RespondQueryTaskCompleted should pass this value for proper routing.
The weighted list of poller groups IDs that client should use for future polls to this task queue. Client is expected to: 1. Maintain minimum number of pollers no less than the number of groups. 2. Try to assign the next poll to a group without any pending polls, 3. If every group has some pending polls, assign the next poll to a group randomly according to the weights.
SDK capability details.
Used in:
True if the SDK can handle speculative workflow task with command events. If true, the server may choose, at its discretion, to discard a speculative workflow task even if that speculative task included command events the SDK had not previously processed. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "with" used to describe the workflow task. --)
Used as request type in: WorkflowService.StartWorkflowExecution
Used as field type in:
Serialized arguments to the workflow. These are passed 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.
The identity of the client who initiated this request
A unique identifier for this start request. Typically UUIDv4.
Defines whether to allow re-using the workflow id from a previously *closed* workflow. The default policy is WORKFLOW_ID_REUSE_POLICY_ALLOW_DUPLICATE. See `workflow_id_conflict_policy` for handling a workflow id duplication with a *running* workflow.
Defines how to resolve a workflow id conflict with a *running* workflow. The default policy is WORKFLOW_ID_CONFLICT_POLICY_FAIL. See `workflow_id_reuse_policy` for handling a workflow id duplication with a *closed* workflow.
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/
Request to get the first workflow task inline in the response bypassing matching service and worker polling. If set to `true` the caller is expected to have a worker available and capable of processing the task. The returned task will be marked as started and is expected to be completed by the specified `workflow_task_timeout`.
These values will be available as ContinuedFailure and LastCompletionResult in the WorkflowExecutionStarted event and through SDKs. The are currently only used by the server itself (for the schedules feature) and are not intended to be exposed in StartWorkflowExecution.
Time to wait before dispatching the first workflow task. Cannot be used with `cron_schedule`. If the workflow gets a signal before the delay, a workflow task will be dispatched and the rest of the delay will be ignored.
Callbacks to be called by the server when this workflow reaches a terminal state. If the workflow continues-as-new, these callbacks will be carried over to the new execution. Callback addresses must be whitelisted in the server's dynamic configuration.
Metadata on the workflow if it is started. This is carried over to the WorkflowExecutionInfo for use by user interfaces to display the fixed as-of-start summary and details of the workflow.
Links to be associated with 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.
Defines actions to be done to the existing running workflow when the conflict policy WORKFLOW_ID_CONFLICT_POLICY_USE_EXISTING is used. If not set (ie., nil value) or set to a empty object (ie., all options with default value), it won't do anything to the existing running workflow. If set, it will add a history event to the running workflow.
Priority metadata
Deployment Options of the worker who will process the eager task. Passed when `request_eager_execution=true`.
Time-skipping configuration. If not set, time skipping is disabled.
Used as response type in: WorkflowService.StartWorkflowExecution
Used as field type in:
The run id of the workflow that was started - or used (via WorkflowIdConflictPolicy USE_EXISTING).
If true, a new workflow was started.
Current execution status of the workflow. Typically remains WORKFLOW_EXECUTION_STATUS_RUNNING unless a de-dupe occurs or in specific scenarios handled within the ExecuteMultiOperation (refer to its docs).
When `request_eager_execution` is set on the `StartWorkflowExecutionRequest`, the server - if supported - will return the first workflow task to be eagerly executed. The caller is expected to have a worker available to process the task.
Link to the workflow event.
Used in:
Rate Limit to be updated
Reason for why the rate limit was set.
Used in:
A new id to be added to an existing compatible set.
A build id which must already exist in the version sets known by the task queue. The new id will be stored in the set containing this id, marking it as compatible with the versions within.
When set, establishes the compatible set being targeted as the overall default for the queue. If a different set was the current default, the targeted set will replace it as the new default.
Used in:
A build ID in the set whose default will become the merged set default
A build ID in the set which will be merged into the primary set
Adds the rule to the list of redirect rules for this Task Queue. There can be at most one redirect rule for each distinct Source Build ID.
Used in:
This command is intended to be used to complete the rollout of a Build ID and cleanup unnecessary rules possibly created during a gradual rollout. Specifically, this command will make the following changes atomically: 1. Adds an assignment rule (with full ramp) for the target Build ID at the end of the list. 2. Removes all previously added assignment rules to the given target Build ID (if any). 3. Removes any fully-ramped assignment rule for other Build IDs.
Used in:
To prevent committing invalid Build IDs, we reject the request if no pollers has been seen recently for this Build ID. Use the `force` option to disable this validation.
Used in:
By default presence of one unconditional rule is enforced, otherwise the delete operation will be rejected. Set `force` to true to bypass this validation. An unconditional assignment rule: - Has no hint filter - Has no ramp
Used in:
Inserts the rule to the list of assignment rules for this Task Queue. The rules are evaluated in order, starting from index 0. The first applicable rule will be applied and the rest will be ignored.
Used in:
Use this option to insert the rule in a particular index. By default, the new rule is inserted at the beginning of the list (index 0). If the given index is too larger the rule will be inserted at the end of the list.
Replaces the assignment rule at a given index.
Used in:
By default presence of one unconditional rule is enforced, otherwise the replace operation will be rejected. Set `force` to true to bypass this validation. An unconditional assignment rule: - Has no hint filter - Has no ramp
Replaces the routing rule with the given source Build ID.
Used in:
(-- api-linter: core::0134=disabled aip.dev/not-precedent: Update RPCs don't follow Google API format. --)
Used as request type in: WorkflowService.UpdateWorkflowExecution
Used as field type in:
The namespace name of the target Workflow.
The target Workflow Id and (optionally) a specific Run Id thereof. (-- api-linter: core::0203::optional=disabled aip.dev/not-precedent: false positive triggered by the word "optional" --)
If set, this call will error if the most recent (if no Run Id is set on `workflow_execution`), or specified (if it is) Workflow Execution is not part of the same execution chain as this Id.
Specifies client's intent to wait for Update results. NOTE: This field works together with API call timeout which is limited by server timeout (maximum wait time). If server timeout is expired before user specified timeout, API call returns even if specified stage is not reached. Actual reached stage will be included in the response.
The request information that will be delivered all the way down to the Workflow Execution.
Used as response type in: WorkflowService.UpdateWorkflowExecution
Used as field type in:
Enough information for subsequent poll calls if needed. Never null.
The outcome of the Update if and only if the Workflow Update has completed. If this response is being returned before the Update has completed then this field will not be set.
The most advanced lifecycle stage that the Update is known to have reached, where lifecycle stages are ordered UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_UNSPECIFIED < UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_ADMITTED < UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_ACCEPTED < UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_COMPLETED. UNSPECIFIED will be returned if and only if the server's maximum wait time was reached before the Update reached the stage specified in the request WaitPolicy, and before the context deadline expired; clients may may then retry the call as needed.
Link to the update event. May be null if the update has not yet been accepted.