Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unthreaded receipt is not returned in the next syncs #17247

Open
florianduros opened this issue May 30, 2024 · 7 comments
Open

Unthreaded receipt is not returned in the next syncs #17247

florianduros opened this issue May 30, 2024 · 7 comments

Comments

@florianduros
Copy link
Member

florianduros commented May 30, 2024

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:

  • Unread threads
  • Main timeline is read
  • The last event of the room is an user renaming

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
Copy link
Member

devonh commented Jun 19, 2024

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.

@devonh
Copy link
Member

devonh commented Jun 19, 2024

So a couple of questions:

  • Is the behaviour I described not the expected outcome?
  • If the behaviour I described is the expected outcome, then is there any other information you can provide that might have been necessary to reproduce this issue? (ie. type of room, ordering of messages, any special room settings, etc.)

@clokep
Copy link
Contributor

clokep commented Jun 19, 2024

@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
Copy link
Member Author

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
Copy link
Member

devonh commented Jun 21, 2024

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
Copy link

kieranlane commented Jul 29, 2024

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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants