Messages not being marked as read after latest update
Steps to reproduce
- Where are you starting? What can you see? Any state. I can see notifications (either a green dot on threads or a number in a circle by a room)
- What do you click? On a thread or on a room and I scroll to the very bottom.
Outcome
What did you expect?
The green dot by a thread or number in a circle by a room to disappear.
What happened instead?
Messages (rooms, and threads) are not being marked as read even when I click in them and scroll to the very bottom. I think even clicking the three dots menu and clicking "Mark as read" does nothing.
Another user has confirmed this as well.
Operating system
Windows
Application version
Element version: 1.11.97
How did you install the app?
From element.io/get-started
Homeserver
matrix.org
Will you send logs?
No
I can confirm this issue is present on 1.11.99 and 1.11.89 also, not sure if helpful but I noticed Cinny does not have this issue https://cinny.in/
Confirming this issue happening. For me it has started happening only after I select SSS in labs.
Will you send logs? No
Without logs there is nothing to look at here
@escix thanks but you are not the reporter, it is their logs we need. Then any further reports we can confirm they are the same issue if their logs are included.
I have made a rageshake, the issue seems to be present on Element Web also.
@escix thanks but you are not the reporter, it is their logs we need. Then any further reports we can confirm they are the same issue if their logs are included.
Noted 👍
Please can I note that the issue is on both Element Desktop and Element Web, the issue is not exclusive to either method of accessing Element.
I can also now confirm that the reading of messages is not instant on Element X on Android either.
All submitted logs so far point to this being a matrix.org infrastructure issue, rather than an Element Web/Desktop issue. Impact on Element X may be different as it uses SSS & separately does not rely on server unread counts
All submitted logs so far point to this being a
matrix.orginfrastructure issue, rather than an Element Web/Desktop issue. Impact on Element X may be different as it uses SSS & separately does not rely on server unread counts
I am inclined to disagree, when using Cinny, messages show as read instantly using the same matrix.org infrastructure. I think Element needs to be able to properly queue requests to mark messages as read on the server and the client should pre-emptively mark the message as read once the request has been sent to a queue before the server has even responded, I'm guessing that's what Cinny does.
I've noticed over the last few days that the read notifications disappearing are tied to the server speed, some days it has been near enough instant and others it takes some time. Would it be possible to ensure that read notifications are processed on the client side rather than solely sending and receiving requests to the server to determine whether a chat or room has been read? This would alleviate the issue.
The ability to mark all messages as unread would be quite helpful too, the Matrix client I mentioned in my previous comment Cinny is able to do this, I find it helpful as I'm a part of lots of rooms I don't always need to participate in.
I've sent a rageshake from my account on element.io for this issue.
@anoadragon453 I can definitely see m.read API hits for the room you're having issue with
2025-06-11T09:32:02.450Z D FetchHttpApi: --> POST https://element.ems.host/_matrix/client/v3/rooms/<room_id>/receipt/m.read/<event_id>
They are all for event with ID %24sjAJqPnh7YEZ4JtWJOMgtji3Qb2p9Z18z7g2tzxXXRY - do you know which event that is in relation to the head of the timeline?
@t3chguy how would I find that out from my Element Desktop client? Also why does it have a % prefix? Does that imply a local event that hasn't yet got an event ID from the homeserver?
@anoadragon453 url encoding, my bad $sjAJqPnh7YEZ4JtWJOMgtji3Qb2p9Z18z7g2tzxXXRY
I suggest not trying from Element given if there is a bug with message ordering/similar then we would not be seeing under it by doing so
That would be a membership join event:
{
"content": {
"avatar_url": "mxc://xeon-e5.vcpu.hu/VcEOEhTjaIjpfizIpfcxLZod",
"displayname": "Rubben",
"membership": "join"
},
"origin_server_ts": 1749593794496,
"sender": "@rubben:xeon-e5.vcpu.hu",
"state_key": "@rubben:xeon-e5.vcpu.hu",
"type": "m.room.member",
"unsigned": {
"replaces_state": "$v-p0LJ7pEvRJMKxpwIub_Zm3dWCLSkmz9UU5ZK0qyfc",
"prev_content": {
"avatar_url": "mxc://xeon-e5.vcpu.hu/VcEOEhTjaIjpfizIpfcxLZod",
"displayname": "Rubben 🇨🇳",
"membership": "join"
},
"prev_sender": "@rubben:xeon-e5.vcpu.hu",
"membership": "join"
},
"event_id": "$sjAJqPnh7YEZ4JtWJOMgtji3Qb2p9Z18z7g2tzxXXRY",
"room_id": "!itCOeHerJPucwbZJDz:element.io"
}
which in my client's timeline is the latest event.
I'm waiting for an internal process to clear before I can give you information on the homeserver's view of the timeline...
@anoadragon453 is the process cleared yet?