Giters

firebase / firebase-admin-go

Firebase Admin Go SDK

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

No way to respect RetryAfter for retryable errors

froodian opened this issue · comments

commented

Describe your environment

  • Operating System version: Ubuntu latest
  • Firebase SDK version: v4.13.0
  • Library version: v4.13.0
  • Firebase Product: messaging

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:

  • As an integrator of "firebase.google.com/go/v4/messaging", send many messages in a loop until you receive a quota exceeded error
  • Attempt to retry the quota exceeded error at an appropriate time - this information is not exposed by the Firebase SDK despite coming from the Firebase API
commented

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?

commented

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 firebase.google.com/go/v4/errorutils package to accomplish that with today's code - we'll attempt that approach imminently.