element-hq / synapse

Synapse: Matrix homeserver written in Python/Twisted.
https://element-hq.github.io/synapse
GNU Affero General Public License v3.0
1.43k stars 167 forks source link

Unthreaded receipt is not returned in the next syncs #17247

Open florianduros opened 4 months ago

florianduros commented 4 months ago

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:

POST https://element.ems.host/_matrix/client/v3/rooms/!jSkNtsjcsXfCRJwGpp%3Amatrix.org/receipt/m.read/%24UVcMglbqEZkuH2fq5zzbH-gQGyIU3MKr83qdtWUJwHg

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

devonh commented 3 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.

devonh commented 3 months ago

So a couple of questions:

clokep commented 3 months ago

@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.

florianduros commented 3 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)

  • 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.

devonh commented 3 months ago

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.

kieranlane commented 2 months ago

Hi @devonh @florianduros, just following up on this as trying to clear away old tickets before the move to JIRA, this appears related to two support tickets 1 2 in Zammad. Looks like perhaps this is pending logs?

florianduros commented 2 months ago

Hi, I'll try to reproduce it next week and provide logs.