My use case is to retry for specific error types and my understanding is that Using retry policy alongside wrapping my errors into retryable/non-retryable error would work.
My question is that: is retry policy applicable to platform (temporal) error? in other words, if an error is thrown by temporal itself, will the activity be re-executed? assume retry policy allows retry.
There are specific scenarios when an activity task can be lost in transit after it is marked as started. In this case, it will be marked as timed out after StartToCloseTimeout and retried according to the retry options.
Is there a chance an error may be returned/thrown after user defined activity code has been executed?
My activity is calling an external API, which is not able to provide idempotency guaranteed, so I want my activity to retry only for some specific error types.
Return an ApplicationError with NonRetryable set to true to ignore the retry policy.
BTW Have you did this course?
Thanks for pointing out.
Just realize that activity timeout will trigger retry for the activity, which may be dangerous for my use case, since the external API does not have idempotency in place.
Is there a way to disable retry for activity timeout and allow retry for specific error types (error type can be decided based on the external API response).
Currently there is no way to have a different retry options for different error types besides marking ApplicationError as non retryable.
You have to perform all retries from the workflow code to support your use case. To disable all server side retries set maxAttempts to 1.