Add resource ID to the http header for API requests

[xwduan]

Is your feature request related to a problem? Please describe.

Include workflowId in the header will enable the api gateway/frontend route the workflow request to correct active cluster without having to decode/open the request payload

Describe the solution you'd like

Workflow requests are requests for a specific workflow, i.e. StartWorkflow, RespondWorkflow/Activity, SignalWorkflow etc.

For actions initiated from the SDK (e.g., StartWorkflow, SignalWorkflow, TerminateWorkflow), the SDK needs to add the workflowId to the request header.

For action-after-poll requests (i.e., RespondWorkflow/ActivityTask), SDK only needs to attach the header from the matching poll response to the following API calls.

Additional context

server will add header at the poll response

Per-SDK Tickets

• Go -
• Java -
• Core -
• TypeScript -
• Python -
• .NET -
• Ruby -
• PHP -
• Temporal CLI -

[cretz]

Unlike the namespace header, these values are in differing places depending on request (some inside workflow_execution, some top-level). Also, this will surely expand to standalone activities, schedules, etc and will need to apply to newer RPC calls.

I propose the approach be via proto annotations that simple code generators in Go, Java, TypeScript, and Rust can use to extract message. So it would look something like this in https://github.com/temporalio/api/blob/master/temporal/api/workflowservice/v1/service.proto:

    rpc RequestCancelWorkflowExecution (RequestCancelWorkflowExecutionRequest) returns (RequestCancelWorkflowExecutionResponse) {
        option (google.api.http) = {
            post: "/namespaces/{namespace}/workflows/{workflow_execution.workflow_id}/cancel"
            body: "*"
            additional_bindings {
                post: "/api/v1/namespaces/{namespace}/workflows/{workflow_execution.workflow_id}/cancel"
                body: "*"
            }
        };
        option (temporal.api.protometa.request-header) {
            header: "temporal-resource-id"
            value: "{workflow_execution.workflow_id}"
        };
    }

The code generators to make the interceptors needed to build this aren't that hard and this will give us future proofing.

[bergundy]

Proto annotations is the best way to go about this. I would enforce that the option is always set and have a variant that opts out of this (e.g. for list APIs).

        options (temporal.api.protometa.request-header) {
            not_set: true
        };

[cretz]

PoC of how this might work:

• cretz/temporal-api@fe8c062 - API changes for adding the annotation and using it
• cretz/temporal-api-go@d43d11d - Code generated utility to extract headers for Go (would have one in Java, TS, and Rust)
• cretz/temporal-sdk-go@e75bb9a - Applying of the utility in Go

Not as confident that every RPC should have to opt-out of the annotation here, but that doesn't have to be decided to develop the feature if we decide we want this feature

[cretz]

Also, I have adjusted the title to reflect a more general nature, and we have acknowledged the following:

• This is an optional optimization header that is not required by clients and does not affect behavior from a user-POV
• Server side does not trust this header implicitly, the request body is the true source of information about the resource