Open florianduros opened 4 months ago
When I try to reproduce this it seems to me like things are working as expected. But maybe my expectations don't line up with what is actually expected.
So here's what I'm doing: (running synapse v1.107.0 locally, using app.element.io as a client)
This puts things in the following state:
If I now do a POST as mentioned above using the eventID for userA's display name change, the unread symbol on the Threads icon goes away for userA.
Now, if userA's last event was before the last event in the thread (ie. userA sends another display name change, then userB sends another message in the thread):
As far as I can tell, this is the desired behaviour.
So a couple of questions:
@devonh Sounds like you're correct to me, but I've found drawing out the DAGs (including relations) and labeling each node to be immensely beneficial in these situations.
When I try to reproduce this it seems to me like things are working as expected. But maybe my expectations don't line up with what is actually expected.
So here's what I'm doing: (running synapse v1.107.0 locally, using app.element.io as a client)
- create a room as userA (private, unencrypted)
- invite userB
- join the room as userB
- userA sends a message
- userB sends a message
- userB sends a threaded reply to UserA's message
- userA changes their display name
This puts things in the following state:
- userA has read the main timeline
- userA has an unread notification on the Threads icon
- userB has read both the main timeline & the thread
If I now do a POST as mentioned above using the eventID for userA's display name change, the unread symbol on the Threads icon goes away for userA.
Now, if userA's last event was before the last event in the thread (ie. userA sends another display name change, then userB sends another message in the thread):
When sending the POST using the event ID of userA's latest name change event, which is the latest event in the main timeline, the unread symbol on the Threads icon remains for userA
- which I believe is due to the receipt referencing an event in the timeline that is older than the latest event in the room (ie. the newer thread event)
As far as I can tell, this is the desired behaviour.
Yes this is the expected behaviour but it is not the behaviour I'm seeing every time when I'm using EW + element homeserver.
If I'm using your example, sometimes (I don't know what it is causing this behaviour) when userA send an unthreaded receipt to the last event Id, the next sync doesn't include our new receipt. In EW, the userB thread is viewed as seen thanks to an EW internal mechanism but if EW is reloaded, the thread is unread again (because the receipt was missing in the sync).
A lot of unread spikes are happening due to this missing receipt in the sync.
I can provide real data, I always have some rooms suffering this behaviour.
If you could provide data/logs around the time where this is happening that could be very helpful. I am failing to reproduce this issue with my local setup.
Hi, I'll try to reproduce it next week and provide logs.
Description
I'm investigating cases of stuck unread on EW. When I'm sending an unthreaded receipt on a room with unread threads, my receipt doesn't appear in the next syncs. Maybe is due to that the last event of the room is an user renaming
Steps to reproduce
In a room:
I send an unthreaded receipt:
The next syncs don't include my receipt.
RoomId: !jSkNtsjcsXfCRJwGpp:matrix.org Last important eventId: $UVcMglbqEZkuH2fq5zzbH-gQGyIU3MKr83qdtWUJwHg
Homeserver
element.io
Synapse Version
1.107.0
Installation Method
I don't know
Database
.
Workers
Single process
Platform
.
Configuration
No response
Relevant log output
Anything else that would be useful to know?
No response