FR: idempotency_key for messaging.send()

Describe your environment

"firebase-admin": "~5.11.0" We use RTDB, Auth, Analytics, Storage, Messaging, PubSub

Describe the problem

It’d be useful if the messaging() product could include an idempotency_key for a message we wish to send to a user.

We use Firebase Functions to respond to RTDB events to send push notifications to users. Occasionally, we receive an error from the FCM service (e.g., Error: fcm.googleapis.com network timeout. Please try again.). We could enable retries on the Cloud Function to attempt to resend the push notification in the event of a function error. However, CF retries may loop for several days. Imagine a scenario where something in the function causes it to error, but after the message delivery is successful… the user may receive (many, many) duplicate push notifications.

We could persist the message ID to the RTDB or elsewhere after successfully sending the push notification, and then check this field before subsequent runs to ensure the message is only sent once.

However, what happens if the DB write fails for some reason? Ideally the FCM system would handle this for us if we provide an idempotency_key of some type. As duplicate push notifications would be a massively big problem for user experience, perhaps it could be something core to the FCM product.

[hiranya911]

The FCM team has closed that feature request as “Won’t fix”. They recommend including a custom-generated identifier in each message sent out (possibly as a data field), and then collapsing the duplicates at the receiver end:

this is solvable by the app developer creating a identifier for each message and including it in the payload. they can then collapse the dupes on their side. The duplication risk should be quite limited hence the recommendation to do this within the app.

If you wish to follow up further, report directly at https://firebase.google.com/support (mention the original issue ID 77217406)

[evgeny-myasishchev]

I am looking for exactly the same thing. Receiver-level deduplication will not help. It may only work if the app is active which is not always the case. It’s frustrating that the GCP team is refusing to add such a common feature in messaging systems forcing users to implement it, which is not always trivial and possible as other commenters mentioned.