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.
Source code
Downstream issue
Forum discussion
When a
429 RESOURCE_EXHAUSTEDerror is returned, the API response includes a suggested retry delay ingoogle.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
retryDelayfromgoogle.rpc.RetryInfoin 429 responses and use that value (with optional jitter) instead of fixed exponential backoff. When noretryDelayis provided, fall back to exponential backoff.Source code
Downstream issue
Forum discussion