An infinite retry on 429 is a bad pattern without an ability to do exponential back offs. Every service is different in terms of how they treat a client when it returns 429s.

In some cases it might count against call limits. And in some cases services might even blacklist a client.

Here is an example of how Key Vault expects clients to retry instead of infinite linear retry:
https://docs.microsoft.com/en-us/azure/key-vault/key-vault-ovw-throttling#how-to-throttle-your-app-in-response-to-service-limits

An important point worth highlighting from the doc:

failed requests that return a 429 count towards the throttle limits tracked by Key Vault.

Real world example:
40 create certificate calls in 10 secs (KV allows 10 creates per 10 seconds) lead to 3.48K calls because of Go SDK's call pattern. :(

Based on this: #322

DoRetryForStatusCodes will be fixed to return the last response when the context is cancelled.

This is a stop gap solution. Because now the client has to add retry logic on top of what's provided by SDK.

SDK should also let the caller override retry pattern per API call and/or retry code. This is crucial because each Azure service behaves differently and a single type of call pattern doesn't fit all cases. This is a good solution vs compromise of:

Write your own sender func that doesn't use DoRetryForStatusCodes but some variant of it, then call *Preparer(), CustomSender(), *Responder() individually.

or

Cancelling the context.

References:

1. https://github.com/Azure/go-autorest/pull/324/files
2. autorest.DoRetryForStatusCodes infinitely retries on http.StatusTooManyRequests statuscode #322