Enable setting of Temporal headers through cli

[Tamoghnasen9]

What was changed

Support setting of Temporal headers in workflows

Why?

The cli doesn't support the setting of workflow headers. With this change we would be able to pass the headers to Workflows using cli.

Checklist

1. Closes - [Feature Request] Allow setting Temporal headers when starting workflow #876

2. How was this tested:

• Brought up the dev server using : temporal server start-dev
• Build the cli locally and passed the --headers flag to start a workflow. Checked in Temporal UI, the Header section shows the headers set in Workflow.

3. Any docs updates needed?
   https://docs.temporal.io/cli/workflow

[CLAassistant]

All committers have signed the CLA.

[cretz]

I think this setting should only be on commands where it makes sense, namely workflow start, execute, query, signal, and update (and any signal-with-start or update-with-start).

[Tamoghnasen9]

Ok. Limited it to:

• workflow execute
• workflow execute-update-with-start
• workflow signal
• workflow signal-with-start
• workflow start
• workflow start-update-with-start
• workflow query
• workflow update start
• workflow update execute

[cretz]

I think instead of this approach where we store options and make a new client, I think we should have an always-set "header context propagator" that extracts the headers from a known key in the context, and just call something like cl.UpdateWorkflow(ContextWithHeaders(updateStartOpts.Headers), ... where ContextWithHeaders creates a context with that key if there are any headers.

[cretz]

Another thing I noticed while reviewing concerning how payload data is represented. I will also see about getting a CLI team member here to review/approve.

[cretz]

Suggested change

	const cliHeaderContextKey = "worflow-headers"
	const cliHeaderContextKey = "workflow-headers"

Or better:

Suggested change

	const cliHeaderContextKey = "worflow-headers"
	type cliHeaderContextKey struct{}

And use the empty struct when accessing

[cretz]

Hrmm, in addition to not wanting to use server utilities in here, I think this may need to be raw data. A user should be able to provide foo="var" or foo=1 and not have the latter become foo="1". They should be able to provide foo={"bar": "baz"}. This is the same approach that is taken everywhere else that accepts payloads, like for --search-attribute and --memo, can we match those (i.e. use stringKeysJSONValues)?

[Tamoghnasen9]

Thanks, implemented this.

[cretz]

Looks great! Will let CLI team review.

[spkane31]

Can you add a test for this change? You should be able to do something like this (heavy pseudocode):

res := s.Execute("workflow", "start", ..., "--headers", "someHeader=123",...)

s.Client.GetWorkflowHistory(...)

startedEvent := <first enums.EVENT_TYPE_WORKFLOW_EXECUTION_STARTED eventType>

headers := startedEvent.GetWorkflowExecutionStartedEventAttributes().GetHeaders()

require.Equal(t, headers.Get("someHeader"), "123")

that's not perfect by any means but that's the gist of what a test for this should look like.

[Tamoghnasen9]

Can you add a test for this change? You should be able to do something like this (heavy pseudocode):

res := s.Execute("workflow", "start", ..., "--headers", "someHeader=123",...)

s.Client.GetWorkflowHistory(...)

startedEvent := <first enums.EVENT_TYPE_WORKFLOW_EXECUTION_STARTED eventType>

headers := startedEvent.GetWorkflowExecutionStartedEventAttributes().GetHeaders()

require.Equal(t, headers.Get("someHeader"), "123")

that's not perfect by any means but that's the gist of what a test for this should look like.

Done @spkane31