CODEWITHSUNDEEP
firebasefirebase-cloud-messaging
Mirko Lugano
Mirko Lugano

Reputation: 985

Firebase Cloud Messaging: "Topic Quota Exceeded"

I have a webapp and a Windows Service which communicate using Firebase Cloud Messaging. The webapp subscribes to a couple of Topics to receive messages, and Windows Service App sends messages to one of these Topics. In some cases it can be several messages per seconds, and it gives me this error:

FirebaseAdmin.Messaging.FirebaseMessagingException: Topic quota exceeded

I don't quite get it. Is there a limit to messages that can be sent to a specific topic, or what is the meaning? I have found until now only info about topic names and subscription limits, but I actually couldn't find anything about "topic quota", except maybe this page of the docs (https://firebase.google.com/docs/cloud-messaging/concept-options#fanout_throttling) although I am not sure it refers to the same thing, and in case if and how it can be changed. In the Firebase Console I can't find anything either. Has anybody got an idea?

Upvotes: 2

Views: 1171

Answers (2)

Eliott Bouvard
Eliott Bouvard

Reputation: 180

It could be one of these issue :

1. Too high subscriptions rates
Like noted here

The frequency of new subscriptions is rate-limited per project. If you send too many subscription requests in a short period of time, FCM servers will respond with a 429 RESOURCE_EXHAUSTED ("quota exceeded") response. Retry with exponential backoff. But this don't seem to be your problem as you don't open new subscriptions, but instead send messages at high rate.

2. Too many messages sent to on device
Like noted here

Maximum message rate to a single device For Android, you can send up to 240 messages/minute and 5,000 messages/hour to a single device. This high threshold is meant to allow for short term bursts of traffic, such as when users are interacting rapidly over chat. This limit prevents errors in sending logic from inadvertently draining the battery on a device.

For iOS, we return an error when the rate exceeds APNs limits.

Caution: Do not routinely send messages near this maximum rate. This could waste end users’ resources, and your app may be marked as abusive.

Final notes
Fanout throttling don't seems to be the issue here, as the rate limit is really high.

Best way to fix your issue would be :

  • Lower your rates, control the number of "devices" notified and overall limit your usage over short period of time
  • Keep you rates as is but implement a back-off retries policy in your Windows Service App
  • Maybe look into a service mor suited for your usage (as FCM is strongly focused on end-client notification) like PubSub

Upvotes: 0

ymz
ymz

Reputation: 6914

Well.. from this document it seems pretty clear that this can happen:

The frequency of new subscriptions is rate-limited per project. If you send too many subscription requests in a short period of time, FCM servers will respond with a 429 RESOURCE_EXHAUSTED ("quota exceeded") response. Retry with exponential backoff.

I do agree that the document should've state how much quantity will trigger the block mechanism instead of just telling the developer to "Retry with exponential backoff". But, at the end of the day, Google also produced this document to help developers understand how to properly implement this mechanism. In a nutshell:

If the request fails, wait 1 + random_number_milliseconds seconds and retry the request.

If the request fails, wait 2 + random_number_milliseconds seconds and retry the request.

If the request fails, wait 4 + random_number_milliseconds seconds and retry the request.

And so on, up to a maximum_backoff time.

My conclusion: reduce the amount of messages send to topic OR implement a retry mechanism to recover unsuccessful attempts

Upvotes: 0

Related Questions