-
Notifications
You must be signed in to change notification settings - Fork 238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No way to respect RetryAfter for retryable errors #603
Comments
Hi @froodian , thanks for filing this feature request. We can't promise a timeline on this, but we will use this issue to track any progress. Are you looking for a feature to disable auto retry in the SDK or would you prefer to access the error responses with retry-after headers keeping the auto-retry feature enabled? |
Hi @lahirumaramba - thanks for the response. In regards to the SDK's internal auto retry, we don't mind that behavior exisitng, but in order to keep requests within our existing timeout expectations, we've actually forked the repo and lowered MaxDelay and ExpBackoffFactor on our fork - so ideally those values would be configurable, or the auto retry would be disableable, so that we don't have to maintain that fork. Regardless of the outcom there, we would want the ability to expose the Retry-After, so that we can retry any requests that make it through that auto retry at an appropriate time - since the initial filing of this issue, we've discovered this comment from a previous issue requesting this, and it appears we may be able to use this |
Describe your environment
Describe the problem
Some messaging errors are retryable, for instance errors for which
messaging.IsQuotaExceeded(err)
returns true. The FCM API requests that the Retry-After response header is respected in retrying these. The Firebase SDK reads the RetryAfter header and respects it when retrying internally, however it does not expose this value to callers, leaving them unable to respect this retry-after.Steps to reproduce:
"firebase.google.com/go/v4/messaging"
, send many messages in a loop until you receive a quota exceeded errorThe text was updated successfully, but these errors were encountered: