Signal-android: MMS group sends duplicate empty MMS to individual conversations

[junitas]

I have:

• [x] searched open and closed issues for duplicates
• [x] read https://github.com/WhisperSystems/Signal-Android/wiki/Submitting-useful-bug-reports

---

Bug description

This may be a duplicate of #6311. I am creating a new issue since the user that reported 6311 seems to only experience it using WiFi Calling mode.

Incoming group messages which include non-Signal users will sometimes send duplicate "empty" MMS messages in the individual conversations of the senders. The MMS message displays a loading icon but never resolves. Eventually the individual MMS message will disappear from the conversation. I have been able to reproduce this twice on my device, but a friend cannot.

Steps to reproduce

• Receive a message from a non-Signal group message

Actual result: Messages in non-Signal groups are received once in the group, and then once in individual conversations as a perpetually loading MMS message which eventually disappears.
Expected result: A message from a non-Signal group is received in that group once

Screenshots

Device info

Device: Nexus 6
Android version: 7.1.1
Signal version: 4.17.0

Link to debug log

https://debuglogs.org/3909860f8aca3f8d6223df9f3d834875944d9c5387e0ee74ff49ec881a41daff

[junitas]

I repeatedly tried to debug this by tracking the threadId using breakpoints in MmsDatabase in the private Optional<InsertResult> insertMessageInbox(IncomingMediaMessage retrieved, String contentLocation, long threadId, long mailbox) method, but couldn't reproduce. The moment I turned off all breakpoints, I could reproduce. I'm wondering if this is some kind of race condition where the mms message is published using the threadId of the individual sender's conversation before the MmsDatabase class is able to set the correct "group" threadId.

[junitas]

For anyone interested, I looked more into this. I'm a bit comfortable with the logical flow of receipt of an MMS message through to its insertion into the inbox but some nuances are beyond me atm.

On an incoming MMS message (individual MMS or group MMS), eventually the message gets to the MmsDatabase insertMessageInbox method, where if the MMS message is in fact a group message, the threadId will be updated from the individual id associated with the sender to the threadId of the group conversation. However, before this happens it seems that the MmsDatabase wants to notify the user of an incoming downloading MMS message, which is our downloading group message, before it does the processing of the threadId. This is done in the MmsDatabase by calling NotificationMmsMessageRecord and passing in the unprocessed threadId. If the MmsDatabase is in the process of downloading the mms message, it will display the duplicated NotificationMmsMessageRecord_downloading_mms_message string in the wrong thread. That code is below:

  public SpannableString getDisplayBody() {
    if (status == MmsDatabase.Status.DOWNLOAD_INITIALIZED) {
      return emphasisAdded(context.getString(R.string.NotificationMmsMessageRecord_multimedia_message));
    } else if (status == MmsDatabase.Status.DOWNLOAD_CONNECTING) {
      return emphasisAdded(context.getString(R.string.NotificationMmsMessageRecord_downloading_mms_message));
    } else {
      return emphasisAdded(context.getString(R.string.NotificationMmsMessageRecord_error_downloading_mms_message));
    }
  }

I hope this is helpful if anyone besides me is interested in further investigation and can reproduce/observe this bug.

[junitas]

I've been able to reliably reproduce this bug by commenting out the line database.delete(TABLE_NAME, ID_WHERE, new String[] {messageId+""}); from MmsDatabase.delete(long messageId).

It seems when an MMS message comes in, the MmsDownloadJob will put an entry into the DB for the message with a DOWNLOAD_CONNECTING status. Later, when the MmsDownloadJob is storing the retrieved MMS message with the correct threadId (based on if it is a group or not), it will call MmsDatabase.delete for the original "unprocessed" MMS message. Inside this call, however, if the deletion fails and returns false, execution will continue as normal but the dangling MMS with the DOWNLOAD_CONNECTING status will still be in the database. This dangling message will then be displayed to the user along with the new, processed group MMS message.

[amadib]

I've been experiencing the same; unable to download especially the first message in an group MMS

[greyson-signal]

This should be resolved.