add GetWorkflowExecutionResult as a system nexus endpoint#781
add GetWorkflowExecutionResult as a system nexus endpoint#781spkane31 wants to merge 18 commits into
Conversation
| option (google.api.http) = { | ||
| post: "/namespaces/{namespace}/workflows/{execution.workflow_id}/wait-for-external-workflow" | ||
| body: "*" | ||
| additional_bindings { | ||
| post: "/api/v1/namespaces/{namespace}/workflows/{execution.workflow_id}/wait-for-external-workflow" | ||
| body: "*" | ||
| } | ||
| }; |
There was a problem hiding this comment.
I don't think we need HTTP for any of the system nexus APIs.
| option (temporal.api.protometa.v1.request_header) = { | ||
| header: "temporal-resource-id" | ||
| value : "workflow:{execution.workflow_id}" | ||
| }; | ||
| } |
There was a problem hiding this comment.
Need to understand how the SDK will use this later when we support direct calls for the system nexus endpoint. For now it doesn't give us any value to add this.
|
|
||
| - included_paths: | ||
| - "**/workflowservice/v1/service.proto" | ||
| - "**/workflownexusservice/v1/service.proto" |
There was a problem hiding this comment.
| - "**/workflownexusservice/v1/service.proto" | |
| - "**/applicationservice/v1/service.proto" |
| // The status of the workflow execution being waited on. This is needed to determine whether the workflow completed successfully or failed. | ||
| temporal.api.enums.v1.WorkflowExecutionStatus status = 1; |
There was a problem hiding this comment.
Didn't we say we're not adding this?
| // (-- api-linter: core::0131::request-name-required=disabled --) | ||
| // (-- api-linter: core::0131::request-unknown-fields=disabled --) | ||
| message GetWorkflowExecutionResultRequest { | ||
| string namespace = 1; |
There was a problem hiding this comment.
We said not to add this. It's always same namespace.
| // The workflow execution to wait for. | ||
| temporal.api.common.v1.WorkflowExecution execution = 2; |
There was a problem hiding this comment.
We should decide and then document what to do if run ID is provided. We may not be able to follow the runs in some cases and we would want a consistent experience.
There was a problem hiding this comment.
I think we should start by not accepting RunID and defaulting to the latest execution. If we get signal that there's a need to expose specific RunIDs in the future we can add support later.
What changed?
Add the
GetWorkflowExecutionResultRPC and expose it as a system nexus operation.Why?
New API for workflows
Breaking changes
No breaking changes
Server PR
TBA