Skip to content

Commit

Permalink
Add ExecuteMultiOperation (temporalio#367)
Browse files Browse the repository at this point in the history
  • Loading branch information
stephanos authored Apr 13, 2024
1 parent dee87b4 commit aa101ea
Show file tree
Hide file tree
Showing 6 changed files with 345 additions and 1 deletion.
202 changes: 202 additions & 0 deletions openapi/openapiv2.json
Original file line number Diff line number Diff line change
Expand Up @@ -1494,6 +1494,46 @@
]
}
},
"/api/v1/namespaces/{namespace}/workflows/execute-multi-operation": {
"post": {
"summary": "ExecuteMultiOperation executes multiple operations within a single workflow.",
"description": "Operations are started atomically, meaning if *any* operation fails to be started, none are,\nand the request fails. Upon start, the API returns only when *all* operations have a response.\n\nUpon failure, the status code equals the status code of the *first* operation that failed to be started; and the\nlist of details contains one `google.grpc.Status` for each requested operation. The failed\noperation(s) have the same error details as if it was executed separately. All other operations have the\nstatus code `Aborted` and `temporal.api.failure.v1.MultiOperationExecutionAborted` is added to the details field.\n\nNOTE: Experimental API.",
"operationId": "ExecuteMultiOperation",
"responses": {
"200": {
"description": "A successful response.",
"schema": {
"$ref": "#/definitions/v1ExecuteMultiOperationResponse"
}
},
"default": {
"description": "An unexpected error response.",
"schema": {
"$ref": "#/definitions/rpcStatus"
}
}
},
"parameters": [
{
"name": "namespace",
"in": "path",
"required": true,
"type": "string"
},
{
"name": "body",
"in": "body",
"required": true,
"schema": {
"$ref": "#/definitions/WorkflowServiceExecuteMultiOperationBody"
}
}
],
"tags": [
"WorkflowService"
]
}
},
"/api/v1/namespaces/{namespace}/workflows/{execution.workflowId}": {
"get": {
"summary": "DescribeWorkflowExecution returns information about the specified workflow execution.",
Expand Down Expand Up @@ -2133,6 +2173,18 @@
}
}
},
"ExecuteMultiOperationRequestOperation": {
"type": "object",
"properties": {
"startWorkflow": {
"$ref": "#/definitions/v1StartWorkflowExecutionRequest",
"title": "Additional restrictions:\n- setting `cron_schedule` is invalid\n- setting `request_eager_execution` is invalid"
},
"updateWorkflow": {
"$ref": "#/definitions/v1UpdateWorkflowExecutionRequest"
}
}
},
"StartOperationResponseAsync": {
"type": "object",
"properties": {
Expand Down Expand Up @@ -2292,6 +2344,19 @@
}
}
},
"WorkflowServiceExecuteMultiOperationBody": {
"type": "object",
"properties": {
"operations": {
"type": "array",
"items": {
"type": "object",
"$ref": "#/definitions/ExecuteMultiOperationRequestOperation"
},
"description": "List of operations to execute within a single workflow.\n\nPreconditions:\n- The list of operations must not be empty.\n- The workflow ids must match across operations.\n- The only valid list of operations at this time is [StartWorkflow, UpdateWorkflow], in this order.\n\nNote that additional operation-specific restrictions have to be considered."
}
}
},
"WorkflowServicePatchScheduleBody": {
"type": "object",
"properties": {
Expand Down Expand Up @@ -4528,6 +4593,29 @@
"description": "- EVENT_TYPE_UNSPECIFIED: Place holder and should never appear in a Workflow execution history\n - EVENT_TYPE_WORKFLOW_EXECUTION_STARTED: Workflow execution has been triggered/started\nIt contains Workflow execution inputs, as well as Workflow timeout configurations\n - EVENT_TYPE_WORKFLOW_EXECUTION_COMPLETED: Workflow execution has successfully completed and contains Workflow execution results\n - EVENT_TYPE_WORKFLOW_EXECUTION_FAILED: Workflow execution has unsuccessfully completed and contains the Workflow execution error\n - EVENT_TYPE_WORKFLOW_EXECUTION_TIMED_OUT: Workflow execution has timed out by the Temporal Server\nUsually due to the Workflow having not been completed within timeout settings\n - EVENT_TYPE_WORKFLOW_TASK_SCHEDULED: Workflow Task has been scheduled and the SDK client should now be able to process any new history events\n - EVENT_TYPE_WORKFLOW_TASK_STARTED: Workflow Task has started and the SDK client has picked up the Workflow Task and is processing new history events\n - EVENT_TYPE_WORKFLOW_TASK_COMPLETED: Workflow Task has completed\nThe SDK client picked up the Workflow Task and processed new history events\nSDK client may or may not ask the Temporal Server to do additional work, such as:\nEVENT_TYPE_ACTIVITY_TASK_SCHEDULED\nEVENT_TYPE_TIMER_STARTED\nEVENT_TYPE_UPSERT_WORKFLOW_SEARCH_ATTRIBUTES\nEVENT_TYPE_MARKER_RECORDED\nEVENT_TYPE_START_CHILD_WORKFLOW_EXECUTION_INITIATED\nEVENT_TYPE_REQUEST_CANCEL_EXTERNAL_WORKFLOW_EXECUTION_INITIATED\nEVENT_TYPE_SIGNAL_EXTERNAL_WORKFLOW_EXECUTION_INITIATED\nEVENT_TYPE_WORKFLOW_EXECUTION_COMPLETED\nEVENT_TYPE_WORKFLOW_EXECUTION_FAILED\nEVENT_TYPE_WORKFLOW_EXECUTION_CANCELED\nEVENT_TYPE_WORKFLOW_EXECUTION_CONTINUED_AS_NEW\n - EVENT_TYPE_WORKFLOW_TASK_TIMED_OUT: Workflow Task encountered a timeout\nEither an SDK client with a local cache was not available at the time, or it took too long for the SDK client to process the task\n - EVENT_TYPE_WORKFLOW_TASK_FAILED: Workflow Task encountered a failure\nUsually this means that the Workflow was non-deterministic\nHowever, the Workflow reset functionality also uses this event\n - EVENT_TYPE_ACTIVITY_TASK_SCHEDULED: Activity Task was scheduled\nThe SDK client should pick up this activity task and execute\nThis event type contains activity inputs, as well as activity timeout configurations\n - EVENT_TYPE_ACTIVITY_TASK_STARTED: Activity Task has started executing\nThe SDK client has picked up the Activity Task and is processing the Activity invocation\n - EVENT_TYPE_ACTIVITY_TASK_COMPLETED: Activity Task has finished successfully\nThe SDK client has picked up and successfully completed the Activity Task\nThis event type contains Activity execution results\n - EVENT_TYPE_ACTIVITY_TASK_FAILED: Activity Task has finished unsuccessfully\nThe SDK picked up the Activity Task but unsuccessfully completed it\nThis event type contains Activity execution errors\n - EVENT_TYPE_ACTIVITY_TASK_TIMED_OUT: Activity has timed out according to the Temporal Server\nActivity did not complete within the timeout settings\n - EVENT_TYPE_ACTIVITY_TASK_CANCEL_REQUESTED: A request to cancel the Activity has occurred\nThe SDK client will be able to confirm cancellation of an Activity during an Activity heartbeat\n - EVENT_TYPE_ACTIVITY_TASK_CANCELED: Activity has been cancelled\n - EVENT_TYPE_TIMER_STARTED: A timer has started\n - EVENT_TYPE_TIMER_FIRED: A timer has fired\n - EVENT_TYPE_TIMER_CANCELED: A time has been cancelled\n - EVENT_TYPE_WORKFLOW_EXECUTION_CANCEL_REQUESTED: A request has been made to cancel the Workflow execution\n - EVENT_TYPE_WORKFLOW_EXECUTION_CANCELED: SDK client has confirmed the cancellation request and the Workflow execution has been cancelled\n - EVENT_TYPE_REQUEST_CANCEL_EXTERNAL_WORKFLOW_EXECUTION_INITIATED: Workflow has requested that the Temporal Server try to cancel another Workflow\n - EVENT_TYPE_REQUEST_CANCEL_EXTERNAL_WORKFLOW_EXECUTION_FAILED: Temporal Server could not cancel the targeted Workflow\nThis is usually because the target Workflow could not be found\n - EVENT_TYPE_EXTERNAL_WORKFLOW_EXECUTION_CANCEL_REQUESTED: Temporal Server has successfully requested the cancellation of the target Workflow\n - EVENT_TYPE_MARKER_RECORDED: A marker has been recorded.\nThis event type is transparent to the Temporal Server\nThe Server will only store it and will not try to understand it.\n - EVENT_TYPE_WORKFLOW_EXECUTION_SIGNALED: Workflow has received a Signal event\nThe event type contains the Signal name, as well as a Signal payload\n - EVENT_TYPE_WORKFLOW_EXECUTION_TERMINATED: Workflow execution has been forcefully terminated\nThis is usually because the terminate Workflow API was called\n - EVENT_TYPE_WORKFLOW_EXECUTION_CONTINUED_AS_NEW: Workflow has successfully completed and a new Workflow has been started within the same transaction\nContains last Workflow execution results as well as new Workflow execution inputs\n - EVENT_TYPE_START_CHILD_WORKFLOW_EXECUTION_INITIATED: Temporal Server will try to start a child Workflow\n - EVENT_TYPE_START_CHILD_WORKFLOW_EXECUTION_FAILED: Child Workflow execution cannot be started/triggered\nUsually due to a child Workflow ID collision\n - EVENT_TYPE_CHILD_WORKFLOW_EXECUTION_STARTED: Child Workflow execution has successfully started/triggered\n - EVENT_TYPE_CHILD_WORKFLOW_EXECUTION_COMPLETED: Child Workflow execution has successfully completed\n - EVENT_TYPE_CHILD_WORKFLOW_EXECUTION_FAILED: Child Workflow execution has unsuccessfully completed\n - EVENT_TYPE_CHILD_WORKFLOW_EXECUTION_CANCELED: Child Workflow execution has been cancelled\n - EVENT_TYPE_CHILD_WORKFLOW_EXECUTION_TIMED_OUT: Child Workflow execution has timed out by the Temporal Server\n - EVENT_TYPE_CHILD_WORKFLOW_EXECUTION_TERMINATED: Child Workflow execution has been terminated\n - EVENT_TYPE_SIGNAL_EXTERNAL_WORKFLOW_EXECUTION_INITIATED: Temporal Server will try to Signal the targeted Workflow\nContains the Signal name, as well as a Signal payload\n - EVENT_TYPE_SIGNAL_EXTERNAL_WORKFLOW_EXECUTION_FAILED: Temporal Server cannot Signal the targeted Workflow\nUsually because the Workflow could not be found\n - EVENT_TYPE_EXTERNAL_WORKFLOW_EXECUTION_SIGNALED: Temporal Server has successfully Signaled the targeted Workflow\n - EVENT_TYPE_UPSERT_WORKFLOW_SEARCH_ATTRIBUTES: Workflow search attributes should be updated and synchronized with the visibility store\n - EVENT_TYPE_WORKFLOW_EXECUTION_UPDATE_ACCEPTED: An update was accepted (i.e. validated)\n - EVENT_TYPE_WORKFLOW_EXECUTION_UPDATE_REJECTED: An update was rejected (i.e. failed validation)\n - EVENT_TYPE_WORKFLOW_EXECUTION_UPDATE_COMPLETED: An update completed\n - EVENT_TYPE_WORKFLOW_PROPERTIES_MODIFIED_EXTERNALLY: Some property or properties of the workflow as a whole have changed by non-workflow code.\nThe distinction of external vs. command-based modification is important so the SDK can\nmaintain determinism when using the command-based approach.\n - EVENT_TYPE_ACTIVITY_PROPERTIES_MODIFIED_EXTERNALLY: Some property or properties of an already-scheduled activity have changed by non-workflow code.\nThe distinction of external vs. command-based modification is important so the SDK can\nmaintain determinism when using the command-based approach.\n - EVENT_TYPE_WORKFLOW_PROPERTIES_MODIFIED: Workflow properties modified by user workflow code\n - EVENT_TYPE_WORKFLOW_EXECUTION_UPDATE_ADMITTED: An update was admitted. Note that not all admitted updates result in this\nevent. See UpdateAdmittedEventOrigin for situations in which this event\nis created.",
"title": "Whenever this list of events is changed do change the function shouldBufferEvent in mutableStateBuilder.go to make sure to do the correct event ordering"
},
"v1ExecuteMultiOperationResponse": {
"type": "object",
"properties": {
"responses": {
"type": "array",
"items": {
"type": "object",
"$ref": "#/definitions/v1ExecuteMultiOperationResponseResponse"
}
}
}
},
"v1ExecuteMultiOperationResponseResponse": {
"type": "object",
"properties": {
"startWorkflow": {
"$ref": "#/definitions/v1StartWorkflowExecutionResponse"
},
"updateWorkflow": {
"$ref": "#/definitions/v1UpdateWorkflowExecutionResponse"
}
}
},
"v1ExternalWorkflowExecutionCancelRequestedEventAttributes": {
"type": "object",
"properties": {
Expand Down Expand Up @@ -7375,6 +7463,95 @@
}
}
},
"v1StartWorkflowExecutionRequest": {
"type": "object",
"properties": {
"namespace": {
"type": "string"
},
"workflowId": {
"type": "string"
},
"workflowType": {
"$ref": "#/definitions/v1WorkflowType"
},
"taskQueue": {
"$ref": "#/definitions/v1TaskQueue"
},
"input": {
"$ref": "#/definitions/v1Payloads",
"description": "Serialized arguments to the workflow. These are passed as arguments to the workflow function."
},
"workflowExecutionTimeout": {
"type": "string",
"description": "Total workflow execution timeout including retries and continue as new."
},
"workflowRunTimeout": {
"type": "string",
"description": "Timeout of a single workflow run."
},
"workflowTaskTimeout": {
"type": "string",
"description": "Timeout of a single workflow task."
},
"identity": {
"type": "string",
"title": "The identity of the client who initiated this request"
},
"requestId": {
"type": "string",
"description": "A unique identifier for this start request. Typically UUIDv4."
},
"workflowIdReusePolicy": {
"$ref": "#/definitions/v1WorkflowIdReusePolicy",
"description": "Defines whether to allow re-using the workflow id from a previously *closed* workflow.\nThe default policy is WORKFLOW_ID_REUSE_POLICY_ALLOW_DUPLICATE.\n\nSee `workflow_id_conflict_policy` for handling a workflow id duplication with a *running* workflow."
},
"workflowIdConflictPolicy": {
"$ref": "#/definitions/v1WorkflowIdConflictPolicy",
"description": "Defines how to resolve a workflow id conflict with a *running* workflow.\nThe default policy is WORKFLOW_ID_CONFLICT_POLICY_FAIL.\n\nSee `workflow_id_reuse_policy` for handling a workflow id duplication with a *closed* workflow."
},
"retryPolicy": {
"$ref": "#/definitions/v1RetryPolicy",
"description": "The retry policy for the workflow. Will never exceed `workflow_execution_timeout`."
},
"cronSchedule": {
"type": "string",
"title": "See https://docs.temporal.io/docs/content/what-is-a-temporal-cron-job/"
},
"memo": {
"$ref": "#/definitions/v1Memo"
},
"searchAttributes": {
"$ref": "#/definitions/v1SearchAttributes"
},
"header": {
"$ref": "#/definitions/v1Header"
},
"requestEagerExecution": {
"type": "boolean",
"description": "Request to get the first workflow task inline in the response bypassing matching service and worker polling.\nIf set to `true` the caller is expected to have a worker available and capable of processing the task.\nThe returned task will be marked as started and is expected to be completed by the specified\n`workflow_task_timeout`."
},
"continuedFailure": {
"$ref": "#/definitions/apifailurev1Failure",
"description": "These values will be available as ContinuedFailure and LastCompletionResult in the\nWorkflowExecutionStarted event and through SDKs. The are currently only used by the\nserver itself (for the schedules feature) and are not intended to be exposed in\nStartWorkflowExecution."
},
"lastCompletionResult": {
"$ref": "#/definitions/v1Payloads"
},
"workflowStartDelay": {
"type": "string",
"description": "Time to wait before dispatching the first workflow task. Cannot be used with `cron_schedule`.\nIf the workflow gets a signal before the delay, a workflow task will be dispatched and the rest\nof the delay will be ignored."
},
"completionCallbacks": {
"type": "array",
"items": {
"type": "object",
"$ref": "#/definitions/v1Callback"
},
"description": "Callbacks to be called by the server when this workflow reaches a terminal state.\nIf the workflow continues-as-new, these callbacks will be carried over to the new execution.\nCallback addresses must be whitelisted in the server's dynamic configuration."
}
}
},
"v1StartWorkflowExecutionResponse": {
"type": "object",
"properties": {
Expand Down Expand Up @@ -7907,6 +8084,31 @@
"default": "UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_UNSPECIFIED",
"description": "UpdateWorkflowExecutionLifecycleStage is specified by clients invoking\nworkflow execution updates and used to indicate to the server how long the\nclient wishes to wait for a return value from the RPC. If any value other\nthan UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_COMPLETED is sent by the\nclient then the RPC will complete before the update is finished and will\nreturn a handle to the running update so that it can later be polled for\ncompletion.\n\n - UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_UNSPECIFIED: An unspecified vale for this enum.\n - UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_ADMITTED: The gRPC call will not return until the update request has been admitted\nby the server - it may be the case that due to a considerations like load\nor resource limits that an update is made to wait before the server will\nindicate that it has been received and will be processed. This value\ndoes not wait for any sort of acknowledgement from a worker.\n - UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_ACCEPTED: The gRPC call will not return until the update has passed validation on\na worker.\n - UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_COMPLETED: The gRPC call will not return until the update has executed to completion\non a worker and has either been rejected or returned a value or an error."
},
"v1UpdateWorkflowExecutionRequest": {
"type": "object",
"properties": {
"namespace": {
"type": "string",
"title": "The namespace name of the target workflow"
},
"workflowExecution": {
"$ref": "#/definitions/v1WorkflowExecution",
"title": "The target workflow id and (optionally) a specific run thereof"
},
"firstExecutionRunId": {
"type": "string",
"description": "If set, this call will error if the most recent (if no run id is set on\n`workflow_execution`), or specified (if it is) workflow execution is not\npart of the same execution chain as this id."
},
"waitPolicy": {
"$ref": "#/definitions/v1WaitPolicy",
"description": "Describes when this request should return - basically whether the\nupdate is synchronous, asynchronous, or somewhere in between."
},
"request": {
"$ref": "#/definitions/apiupdatev1Request",
"description": "The request information that will be delivered all the way down to the\nworkflow execution."
}
}
},
"v1UpdateWorkflowExecutionResponse": {
"type": "object",
"properties": {
Expand Down
Loading

0 comments on commit aa101ea

Please sign in to comment.