I am using temporal to run several of my workflows. I would like to pass contextual information to all of these workflows without including that information in the workflow input. Similar to how header information is passed in http requests without appearing in the body.
What is the recommended way to pass contextual information to workflows without including them in the input? Is this a good use case for the workflow memo functionality?
What type of contextual information and why not make it part of the input?
Technically Temporal does offer headers but we intentionally limit them to interceptors only (used for things like serialized span information for OpenTelemetry). Memos would work, but if you’re willing to set the memo on start, why not set a field in your input dataclass? Also, memos are primarily used for description information and need to be limited in size because how they are stored for listing. We recommend passing needed workflow information via input.
Thanks for the input Chad. I have a proxy service that users call with an input, and the proxy service then calls the correct temporal workflow and passes it that input. I would like the proxy service to be able to inject information about the user/other metadata into the workflow without the user seeing it in the input. I have a proxy service because sometimes I am running workflows on other orchestrators (tech debt…) and I don’t want users to have to care about what goes on behind the proxy.
I was hoping temporal may have some header system I could use to easily pass this data in. Since it doesn’t, I can just have two separate inputs. one input to the proxy, and another input to the workflow which includes the proxy input as well as my contextual information.
How are you going to use this information on the workflow side? If you are going to use inside the workflow, workflow input is the clear best way.
It does. You can make a client interceptor to pass headers when starting a workflow and a worker interceptor to retrieve headers when running a workflow. You can see the OpenTelemetry implementation to see how we use headers to pass/retrieve information from client through workflow, activities, child workflows, etc. Unfortunately we don’t really have a simpler example because we don’t often encourage its use over normal input.
It will be used within the workflows. Based on your inputs, it seems that the workflow input is by far the best solution here.
Thanks for linking this. If my requirements change and I end up needing to shield all the contextual information from the workflow, I will switch to using an interceptor.
Definitely. Above you said “I don’t want users to have to care about what goes on behind the proxy” but if it’s used in workflow code, there is some care happening somewhere if it is used in workflow code (unless you’re hiding it in interceptors at which point headers makes sense).