Signal-android: Signal skips delivery confirmation/read receipts for serial messages

[jbaker6953]

• [x] I have searched open and closed issues for duplicates
• [x] I am submitting a bug report for existing functionality that does not work as intended
• [x] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
• [x] This isn't a feature request or a discussion topic

---

Bug description

I have 'SMS Delivery Reports' and 'Read receipts' both toggled to on. If I send more than one message in a rapid succession, only the last message receives a delivery report or a read receipt, leaving uncertainty whether the preceding messages were delivered and/or read. This is a regression that is new to 4.24.8.

Steps to reproduce

• Toggle 'SMS Delivery Reports' and 'Read Receipts' options
• Rapidly send two or more messages to a single contact

Actual result: Only the last message has the delivery report and read receipt. The preceding messages do not have any indication if they were delivered and/or read.

Expected result: Each message has its own delivery report and read receipt

Screenshots

Device info

Device: Google Pixel XL
Android version: 7.2.1
Signal version: 4.24.8

Link to debug log

[jbaker6953]

This bug is more complicated than initially reported. It appears that envelop information is collapsed for serial messages. This ruins more than delivery reports and read receipts, it also ruins delivery time. See below.

Previous three messages have no timestamp even though they were received at very different times.

[greyson-signal]

So the idea here is that we collapse footers in cases where we think we can save space without losing information. We'll collapse footers if:

• The timestamp that we'd _display_ are identical (note that this generally means we collapse messages that are sent within the same minute, with some wiggle room)
• The message is not in the "sending" state (i.e. the spinny circle icon)
• The message is not in a failure state

We had previously tried to only collapse messages if their delivery statuses were the same, but it ends up looking pretty janky in practice, because messages can go from sending -> sent -> delivered pretty quickly, which can lead to jumpiness as the footers collapse. We figured that because footers would only collapse for messages within the same minute that this was an acceptable compromise. In addition, you can always long-press and go to the message details screen to get more detailed delivery status info.

Now, the more concerning part here is that you said in your second message that footers were collapsing for messages that "were received at very different times". Can you give me more details about the received time of those messages? If they're not within a minute of each other, can you give me the "received" timestamp for the messages in the message details screen?

Thanks!

[jbaker6953]

So the idea here is that we collapse footers in cases where we think we can save space without losing information.

In all my years of texting and using Signal, it has never occurred to me that the footers of messages were taking up unnecessary vertical space, especially considering that vertical space is unlimited and phones are getting taller, not shorter. It seems like a solution in search of a problem because it makes it impossible to determine the status of messages at a glance, instead requiring the user to take several steps and to have to do so for each message individually.

Now, the more concerning part here is that you said in your second message that footers were collapsing for messages that "were received at very different times". Can you give me more details about the received time of those messages? If they're not within a minute of each other, can you give me the "received" timestamp for the messages in the message details screen?

They are within a minute, but not knowing what Signal was trying to do, I was seeing some messages only a few seconds apart getting their own footers and some that were almost a minute apart were not. It's now clear that a message sent at 00:01:59 and another sent at 00:02:01 (two seconds apart) will each get a footer, but a message sent at 00:01:01 and 00:01:59 (58 seconds apart) will not.

My question becomes, what happens when the messages have different statuses? What if one of the messages isn't delivered? Does it get its own footer, or is it forever unknown that the message was undelivered until the user manually checks it with a long press?

[minnmann]

My question becomes, what happens when the messages have different statuses? What if one of the messages isn't delivered? Does it get its own footer, or is it forever unknown that the message was undelivered until the user manually checks it with a long press?

I guess it should not happen very often (if it happens at all) that the most recent message is delivered whereas some previous message is not. While I assume that in theory this could happen (and AFAIK the Signal protocol even has support to handle out-of-order messages), I don't think this is a major problem for the general use.

If a previous message is not yet delivered, it probably would be also true for the most recent one that does have a footer anyway. So if the most recent message is delivered, I just assume that ALL previous messages are delivered, too.
Please correct me, if this assumption is wrong in general.

[greyson-signal]

@jbaker6953 What we're trying to do is eliminate redundant information. In the case of incoming messages, if we collapse the footers, it's because all of those footers would otherwise say the same exact thing. That means that you're not losing any information -- if we showed the footers, they'd all say "2 min" or whatever. You can always long-press and view the message details if you want second-level accuracy. But you're not losing any information compared to the previous design.

In the case of incoming messages, the android client doesn't send out the next message until the previous message sends or fails. We'll show a footer in the case of an error, so that means that if your most recent message is sent and the previous didn't have an error, you know that the previous one was sent.

The only situations where you might lose information is when you send a cluster of messages, less than a minute apart, where the previous message is marked as delivered or read, but the most recent message hasn't been delivered or read yet. In that case, you'll only see the status of the most recent message, whose status is different from the preceding messages. I think it's an ok compromise though. And once again, if you're curious, you can long-press and look at the message details.

Anyway, if you want to continue this, I suggest starting a post on the forum. We reserve github issues for bugs, but this behavior is intentional. Thank you!

[jbaker6953]

The only situations where you might lose information is when you send a cluster of messages, less than a minute apart, where the previous message is marked as delivered or read, but the most recent message hasn't been delivered or read yet. In that case, you'll only see the status of the most recent message, whose status is different from the preceding messages. I think it's an ok compromise though.

It's not a compromise. A compromise is where two or more parties sacrifice to reach middle ground. This is people who don't want to see footers forcing other people to jump through hoops to access that information. They have sacrificed nothing, therefore there is no compromise.