Retry logic should respect server-provided retryDelay from 429 responses #1875
Description
When a 429 RESOURCE_EXHAUSTED error is returned, the API response includes a suggested retry delay in google.rpc.RetryInfo:
{
"error": {
"code": 429,
"message": "You exceeded your current quota... Please retry in 53.016342224s.",
"status": "RESOURCE_EXHAUSTED",
"details": [
{
"@type": "type.googleapis.com/google.rpc.RetryInfo",
"retryDelay": "53s"
}
]
}
}The SDK ignores this value and uses fixed exponential backoff (~1s, ~2s, ~4s, ~8s, ~17s), wasting all 5 retry attempts in ~33 seconds when the server explicitly says to wait ~53 seconds.
Proposed solution
The SDK should parse retryDelay from google.rpc.RetryInfo in 429 responses and use that value (with optional jitter) instead of fixed exponential backoff. When no retryDelay is provided, fall back to exponential backoff.