Implement StartWorkflowExecutionAsync API #5642
Conversation
Shaddoll
requested review from
neil-xie,
davidporter-id-au,
Groxx,
shijiesheng,
agautam478,
jakobht,
3vilhamster,
sankari165,
dkrotx,
taylanisikdemir and
demirkayaender
as code owners
| // propagate the headers from the context to the message | ||
| clientHeaders := common.GetClientHeaders(ctx) | ||
| header := &shared.Header{ | ||
| Fields: map[string][]byte{}, |
There was a problem hiding this comment.
size is known so you can do
Fields: make(map[string][]byte, len(clientHeaders)
| if _, ok := headerExists[ClientIsolationGroupHeaderName]; !ok { | ||
| headers[ClientIsolationGroupHeaderName] = call.Header(ClientIsolationGroupHeaderName) | ||
| } | ||
| return headers |
There was a problem hiding this comment.
this is an important part that I have some knowledge gap.
- do we forward headers to workflows in sync calls?
- by doing this allowlist based header selection would the user be disappointed when they don't see some of the custom headers in their workflow's headers?
There was a problem hiding this comment.
These are the headers either forwarded in sync calls or consumed in sync calls.
For example, isolation group header is used in sync calls for zonal isolation.
There was a problem hiding this comment.
@Groxx I believe you were looking at reducing the set of headers that were either persisted or forwarded, waht's the current status of that?
| headerNames := call.HeaderNames() | ||
| headerExists := map[string]struct{}{} | ||
| for _, h := range headerNames { | ||
| headerExists[h] = struct{}{} |
There was a problem hiding this comment.
I don't feel strongly about this, but I recall Steven making a point about headers not... technically being a map, since they support duplicates under some implementations.
What changed?
Implement StartWorkflowExecutionAsync API
Why?
To implement the new feature
How did you test it?
unit test
Potential risks
Release notes
Documentation Changes