This doc indicates that using the aws sdk gives you out-of-the-box retry functionality.
Then this doc states
// The maximum number of times that a request will be retried for failures.
// Defaults to -1, which defers the max retry setting to the service
// specific configuration.
MaxRetries *int
which tells me that retry logic configuration happens at the service level.
If this is the case, I would expect individual services to document their retry logic configuration. Not only is this not the case in actuality, several (actions of) services seem to imply that they don't provide retry logic, and, instead, discuss how this might be implemented at the application level. See for example dynamodb:
If DynamoDB returns any unprocessed items, you should retry the batch operation on those items. However, we strongly recommend that you use an exponential backoff algorithm. If you retry the batch operation immediately, the underlying read or write requests can still fail due to throttling on the individual tables. If you delay the batch operation using exponential backoff, the individual requests in the batch are much more likely to succeed.
and sqs:
The receive request attempt ID is the token used for deduplication of ReceiveMessage calls.
During a long-lasting network outage that causes connectivity issues between your SDK and Amazon SQS, it's a best practice to provide the receive request attempt ID and to retry with the same receive request attempt ID if the SDK operation fails.
My question is how do I know when a service is handling the retry logic and when I have to implement it at the application level?
