I wanted to append extra tags to the temporal sdk metrics relating to workflow and activity execution that are reported.
For example, the workflow and activity arguments have info which I wanted to tag the existing metrics with.
Can I do that via interceptors where based on the workflowType I can access the arguments and then add it as tags to any metrics that is being reported.
It wasn’t clear if the example in the sample-go project for interceptors work on user defined metrics where in the code you call
GetMetricsHandler. For sdk defined metrics, I’m not sure if that is being called.
would you create an interceptor for the incoming for
ExecuteAcvitity to get the arguments or whatever you want to tag add the info to
context.Context for activities. Also would I have to use Context Propagation to achieve this?
I guess the metrics handler would be something like this…but not clear how you access the workflow/activity arguments
I’m trying to understand how this is needed. The flow:
- workflow executeWrokflow is triggered. I have an injector which grab the params and add some of the fields to the context
- when the metricsHandler is called, it will read the context for the value and append with
Workflow and activity inbound and outbound interceptors are instantiated per request. So you can pass data as fields. So you can intercept ExecuteWorkflow save arguments as a struct field and then use them when intercepting GetMetricsHandler.emphasized text
Thanks. If the worker dies and the workflow is at the halfway point, the new worker on another machine can pick up the job and start where it left off with the same context correct?
I’m probably missing something, but when would you use ContextPropagation? From the docs,
Temporal provides a standard way to propagate a custom context across a Workflow.
In the examples, I see it injecting it at the start of the worker. In my case, i’m trying to do it from when the workflow/activity start.
The root context passed to the worker is a legacy feature used to pass database connections and other dependencies to activity implementations. It was needed as, originally, only pure functions were supported as activity implementations. Now we recommend using structures to define activities and pass these dependencies during structure construction.
You need context propagation to pass context across process boundaries. For example from the client that started workflow to the workflow implementation and from the workflow implementation to an activity implementation.
Interceptors are more feature reach that context propagator and superseded them.
I don’t think you need the context propagation for the use case you initially asked about.