Hi,
I was wondering if its possible to get the retry policy within the activity scope. Basically, we have activities code that is reused in different workflows. We want to capture when the activity fails after the retry policy fails, so we can avoid adding the same code handling in each workflow that calls the activity.
I do see activity.GetInfo(ctx).Attempt
gives you the current attempt number, but can’t see an api for the maxRetries.
Also just curious if temporal provides these type of metrics:
- specific activity/workflow failures (based on workflow type, failed retry policy, etc). I only see metrics generically capturing failed and completed workflows. I think this would be useful for people as part of the client sdk, vs having customers implement this as injectors.
Thanks,
Derek
We want to capture when the activity fails after the retry policy fails, so we can avoid adding the same code handling in each workflow that calls the activity.
Hi, not sure I fully understand the question, workflow code would receive the activity error after all of its retries are done, so regardless of retry policy set (unless you use default retry policy which does not restrict activity retries).
err = workflow.ExecuteActivity(...)
if err != nil {
// activity error after all retries
}
sdk emits activity_execution_failed metric but its counter for each activity invocation (so would include all retries that failed as well).
What i’m looking for is a metric that tracks:
- failures by activity type
- retry policy fails by activity type
I looked at activity_execution_failed
but yeah it doesn’t really tell me what activity type failed or the rate of failure based on retry for that specific activity type.
Sounds like I would have to create my own injectors to emit this type of metrics. In order to do that, I need to be able to access what the retry policy is in the scope of the activity. I want to generically capture this metrics in the activity injector vs. the workflow code.