Bug: FCM - Duplicate Topic Notifications

[roybeitner]

[READ] Step 1: Are you in the right place?

• For issues related to the code in this repository file a Github issue.
• If the issue pertains to Cloud Firestore, read the instructions in the "Firestore issue"
  template.
• For general technical questions, post a question on StackOverflow
  with the firebase tag.
• For general Firebase discussion, use the firebase-talk
  google group.
• For help troubleshooting your application that does not fall under one
  of the above categories, reach out to the personalized
  Firebase support channel.

[REQUIRED] Step 2: Describe your environment

• Operating System version: Any iOS or Android running Flutter 3.00 with firebase_messaging 13.0.0
• Firebase SDK version: 11.0.1
• Firebase Product: FCM (auth, database, storage, etc)
• Node.js version: v16.x AWS Lambda
• NPM version: AWS Lambda

[REQUIRED] Step 3: Describe the problem

Android and iOS users receive at least once a day a duplicate topic notification sent from the Lambda service running the Firebase-Admin SDK.
No duplicate notifications we're generated by our service itself (used extensive logging for each notification sent).
We use the sendAll function (of the SDK) and send the notifications in batches.
The client app does not create a local notification in any part of the code.

Steps to reproduce:

What happened? How can we make the problem occur?
This could be a description, log/console output, etc.

Log from the client receiving a duplicate notification:

D/FLTFireMsgReceiver(11547): broadcast received for message
I/flutter (11547): ----------------------------
I/flutter (11547): {data, blablabla}
I/flutter (11547): 0:1662825724904819%88b82b6688b82b66
I/flutter (11547): Subtitle bla bla bla
I/flutter (11547): Title bla bla bla
I/flutter (11547): 2022-09-10 19:02:04.313
I/flutter (11547): ----------------------------
W/FirebaseMessaging(11547): Unable to log event: analytics library is missing
W/FirebaseMessaging(11547): Missing Default Notification Channel metadata in AndroidManifest. Default value will be used.
I/FirebaseMessaging(11547): Starting download of: imageurl
D/SurfaceView@bee2085(11547): updateSurface: surface is not valid
D/FLTFireMsgReceiver(11547): broadcast received for message
I/flutter (11547): ----------------------------
I/flutter (11547):  {data, blablabla}
I/flutter (11547): 0:1662825734630562%88b82b6688b82b66
I/flutter (11547): Subtitle bla bla bla
I/flutter (11547): Title bla bla bla
I/flutter (11547): 2022-09-10 19:02:14.219
I/flutter (11547): ----------------------------
W/FirebaseMessaging(11547): Unable to log event: analytics library is missing
W/FirebaseMessaging(11547): Missing Default Notification Channel metadata in AndroidManifest. Default value will be used.
I/FirebaseMessaging(11547): Starting download of:imageurl

the "sentTime"s are
2022-09-10 19:02:04.313
2022-09-10 19:02:14.219

Relevant Code:

Sent payload:

 const payload: TopicMessage= {
    topic: topicSomething,
    notification: {
      title,
      body,
      imageUrl: image,
    },
    data: {
     field1,
     field2,
     field3,
     field4,
     field5,
    },
    apns: {
      payload: {
        aps: {
          badge: 1,
          sound: "default",
        },
      },
      headers: {
        "apns-collapse-id": id,
      },
    },
    android: {
      notification: {
        imageUrl,
      },
      collapseKey: id,
      ttl: ONE_DAY_IN_MS,
    },
    webpush: {
      headers: {
        image,
        TTL: ONE_DAY_IN_SECONDS.toString(),
      },
    },
  };

Send command:

const notificationsResponse = await firebase
      .messaging()
      .sendAll([message1, message2, message3, ....]);

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[MarkChrisLevy]

I can confirm, that I encounter the same issue. What is very weird it doesn't happen every single time, but rather from time to time and the number of duplicated notifications device receives varies, minimum 2 but it was even 6 in a few cases. I tried to find the pattern and the only difference I see is that when a message with duplicated notifications is send, the time of execution of sendAll is much longer (at least two times longer) than in messages without duplicates.

Today I had a situation, when a message was send and notifications was duplicated 5 times, but sendAll thrown an error "Error while making request: timeout of 10000ms exceeded", but still the message was send.

In my case, I'm passing 100 messages to sendAll. I'm using 10.0.2 version of firebase-admin within firebase function to send a message.

[roybeitner]

I can confirm, that I encounter the same issue. What is very weird it doesn't happen every single time, but rather from time to time and the number of duplicated notifications device receives varies, minimum 2 but it was even 6 in a few cases. I tried to find the pattern and the only difference I see is that when a message with duplicated notifications is send, the time of execution of sendAll is much longer (at least two times longer) than in messages without duplicates.

Today I had a situation, when a message was send and notifications was duplicated 5 times, but sendAll thrown an error "Error while making request: timeout of 10000ms exceeded", but still the message was send.

In my case, sendAll takes about 100 messages to be send. I'm using 10.0.2 version of firebase-admin.

+1
I'm experiencing exactly the same behavior.

[chong-shao]

Hello, from the "sentTime"s:

2022-09-10 19:02:04.313
2022-09-10 19:02:14.219

Looks like the time difference between the first send and the retry is 10s. Was the retry automatically performed by the Admin SDK or it's your code that implements the retry logic?

[roybeitner]

Hello, from the "sentTime"s:

2022-09-10 19:02:04.313

2022-09-10 19:02:14.219

Looks like the time difference between the first send and the retry is 10s. Was the retry automatically performed by the Admin SDK or it's your code that implements the retry logic?

Performed by the Admin SDK, might be the source of the problem.

[chong-shao]

@lahirumaramba Hi Lahiru, I think the wait time should be extended to 15s. Could you help make the change?