Two "Seen by" dots shown

[rspears74]

Steps to reproduce

In the messages view, in a conversation with one person, I see two "Seen by" dots - one after my most recent message the other user has seen, and one after the last message they sent. Something like this (x represents the "Seen by" dot):

Me: hello
Them: How's it going?
                                     x
Me: Pretty good, you?
                                     x
Me: You there?

Outcome

What did you expect?

I expect to see only one "Seen by" dot, after the most recent of my messages the other user has seen.

What happened instead?

I see two.

Your phone model

Google Pixel 7

Operating system version

Android 13

Application version and app store

Element version 1.5.11

Homeserver

non-public, synapse

Will you send logs?

Yes

Are you willing to provide a PR?

No

[bmarty]

I guess this is coming from the recent changes about read receipt for threads...

[alajovic]

Same problem noticed here.

Samsung Galaxy S22
Android 13
Element 1.5.11 from F-droid
matrix.org server

[B-McDonnell]

I believe this is what @SpiritCroc was referring to here: #6342 (comment). They say they believe it is because of a read marker for both "null" and "main" threads causing issues.

I am also having issues with notifications on Android that started at the same time as the double read markers appeared. Possibly not notifying because it's wrongly considered read?

[Eriatolc]

Probably the same issue here, but the two "Seen by" dots (of the same person) can be at the same place.

Oxygen OS 12 on OnePlus Nord 2T, but add the same issue some weeks ago on my previous OnePlus Nord.
Element 1.5.11 from Play Store.

[SpiritCroc]

Probably the same issue here, but the two "Seen by" dots (of the same person) can be at the same place.

From my experience, it only looks like this due to to reactions. When enabling showing hidden events in the developer options, one receipt is usually on the message itself, and another on the reaction.

[opusforlife2]

For me, I don't have hidden events enabled. And I see this problem even on regular texts without reactions. But I can see how hidden events could be involved. When I've ended a call, the other person's read markers can sometimes double up without any messages in between, which could mean there's a hidden event between them.

[B-McDonnell]

Probably the same issue here, but the two "Seen by" dots (of the same person) can be at the same place.

From my experience, it only looks like this due to to reactions. When enabling showing hidden events in the developer options, one receipt is usually on the message itself, and another on the reaction.

This does not align with my experience. I've been having this issue for weeks and have not personally observed any interactions with reactions

[B-McDonnell]

Did a quick test. It obviously isn't complete. Here's how it went:

In this case, what I was seeing was a delayed bubble. Sometimes, I see that it appears my message is read immediately when I don't believe it has, which is rather the inverse of the behavior I saw in this test. One possible difference is that I had a Windows desktop client open at the same time to compare the placement of read bubbles.

The delayed bubble sometimes got stuck on a single message for multiple events and sometimes updated. I'm not sure of the pattern between the two. For example, between these two states the delayed bubble stayed on the same message despite many messages from both of us between.

Both read bubbles then jumped on their next message:

I do also see that one read bubble can be on a reaction, but I would guess this is expected behavior?

As an aside, here is what they see, which appears to be the same behavior to me:

(some messages with unverified session but they say this is typical even when not using that).

[B-McDonnell]

On notifications: I simply don't receive them most the time since this behavior began (Google Pixel 5, up-to-date Android, installed from F-Droid). They get vibration for one second with the notification showing briefly before vanishing (Google Pixel 7, up-to-date Android, installed from Play Store). Not sure if this issue is related or if it is a separate problem that started around the same time.

[rspears74]

They get vibration for one second with the notification showing briefly before vanishing (Google Pixel 7, up-to-date Android, installed from Play Store).

I seem to get this behavior sometimes too, but not all the time(?) - I'm also Google Pixel 7, current Android, Play Store.

[SpiritCroc]

Probably the same issue here, but the two "Seen by" dots (of the same person) can be at the same place.

From my experience, it only looks like this due to to reactions. When enabling showing hidden events in the developer options, one receipt is usually on the message itself, and another on the reaction.

This does not align with my experience. I've been having this issue for weeks and have not personally observed any interactions with reactions

Note I'm not saying duplicate read receipts are related to reactions. My point is that whenever it looks like duplicated read receipts are attached to the same message, that's usually just because the receipts are "flattened" when there are reactions, and once you have hidden events enabled, the receipts still attach to different events.

[bmarty]

Investigating this issue.

Confirming the main and null issue on read receipt by inspecting the database of benoit10518 account, on a room without any thread:

Event $cIf... is the latest event of the room, and Event $aOg... is the latest event sent by benoit10518.

But there I do not see the issue on the device.

I guess when sending an Event to a room we add a RR to the database, but not using main and this is causing the issue. Still digging.

[B-McDonnell]

Poked around in some blames. I'm guessing the issue can be tracked down to #7474. Matches the timeline and I don't see more recent changes on thread ids' interactions with read receipts since. Lots of null checking going on because threadId can be null, so my first guess would be some logic error there.

It could also be an issue with migrating the database #7640? Maybe a ReadReceiptEntity is getting the wrong threadId (null or main) when it shouldn't, leading to a duplicate?

If this is not a ubiquitous issue, I would guess some edge case happened to a subset of users. Some uncommon logic state, or the migration not properly handling a certain type of events, that sort of thing.

[opusforlife2]

BTW: possible duplicate of #6342.

[SpiritCroc]

FWIW, I've seen the same chat head placement for the same chat across multiple devices on multiple Elements/Element-based clients since the threads update, and it persists across initial syncs. So it seems 100% deterministic from my experiments / if I haven't missed any case.

[B-McDonnell]

Investigating this issue.

Confirming the main and null issue on read receipt by inspecting the database of benoit10518 account, on a room without any thread:

Event $cIf... is the latest event of the room, and Event $aOg... is the latest event sent by benoit10518.

But there I do not see the issue on the device.

I guess when sending an Event to a room we add a RR to the database, but not using main and this is causing the issue. Still digging.

I'd be happy to take a look at the data for the room I'm experiencing this issue in.

I'm not an Android dev — is the best approach setting up an emulator through Android Studio, logging into my account, and using Flipper per flipper.md?

[bmarty]

I'm not an Android dev — is the best approach setting up an emulator through Android Studio, logging into my account, and using Flipper per flipper.md?

Yes. The main issue is that you will not be able to query the database with Flipper. So if there are lots of entries, it can be painful to inspect.

[B-McDonnell]

Okay, here are my results. I had forgotten how much of a pain android development was to get set up the first time.

Not sure what all needs to be censored so I was liberal with it. Note that on the database photos, my friend is censored in pink to distinguish the different userIds

Test

State A

State B

(unfortunately, I did not have it 😞)

State C

Friend's perspective

I had my friend send a screenshot at the end. They said that my second read receipt was also on the $went... message the whole time.

eventId / message reference table

| eventId  | message content      | state(s) |
|----------|----------------------|----------|
| $went... | Seen 14 50           | A,B,C    |
| $0czA... | sample message       | A        |
| $IcDf... | That the issue in... | B        |
| $OhAJ... | Okay, I need you...  | C        |

Insights

Two things I observed here: first, for this test, both my and my friend's second read receipt were on the same $went... message. It would be worth checking further to see if they're always in sync.

Second, compared to the previous test @bmarty ran, there's one more read receipt. The previous test had one single null from the recipient and a null and main from the account owner, if I understand correctly. My test had full symmetry. The discrepancy might be because the previous test didn't have multiple events made and seen by both accounts beforehand, but if it did, that might be our problem.

[opusforlife2]

I've just seen 2 read markers from the same user occupy the same position, meaning that they were grouped. Until now, I've only seen them vertically adjacent, never grouped.

[another-time]

For me there is one read receipt which is real which shows up when the user has actually seen the message, and then there is a fake read receipt that shows up (usually) instantly whenever a message is sent. When the user has actually seen the most recent message, then both read receipts will be on that message, when he hasn't there will be the fake read receipt on the most recent message and the real one somewhere above on the last message he actually saw. And this is only visible on android. On element desktop, I can only see the fake read receipt from android users, so it is impossible to tell if they actually saw the message or not.

[RayBB]

I am still seeing this pretty much daily on the latest version of the app.

[borisrunakov]

Never stopped for me on all versions since reported.

[dav23r]

Like others said, still affects my experience. Would be happy to provide any logs/debug information per request.

[TheEagleByte]

This is showing up a lot for our users. Will often show them along side each other as if multiple people viewed up to that message, but upon looking at the icons and opening it up, they're from the same person. Image below:

[olmari]

Also +1 from here. While not mos urgent thing, most irritating it is.